Skip to content

fix: write tools honor GITLAB_TOKEN fallback (1.15.1)#33

Merged
ttpears merged 1 commit into
mainfrom
fix/write-tool-auth-fallback-32
May 13, 2026
Merged

fix: write tools honor GITLAB_TOKEN fallback (1.15.1)#33
ttpears merged 1 commit into
mainfrom
fix/write-tool-auth-fallback-32

Conversation

@ttpears
Copy link
Copy Markdown
Owner

@ttpears ttpears commented May 13, 2026

Summary

  • Removes the early-exit if (!credentials) throw guard from every write tool handler. The guard short-circuited getClient()'s documented four-step token resolution, so writes failed with User authentication is required... whenever the caller relied on the GITLAB_TOKEN env fallback (stdio, or HTTP without Authorization: Bearer). Reads were unaffected.
  • Applied uniformly to create_issue, create_merge_request, update_issue, delete_issue, update_merge_request, manage_pipeline, create_note, delete_note, update_note, create_broadcast_message, update_broadcast_message, delete_broadcast_message, and the requiresWrite branch of execute_custom_query. getClient() still throws an actionable error if no token at all is configured.
  • Patch bump to 1.15.1 (package.json, .claude-plugin/plugin.json, lockfile synced) and CHANGELOG entry. Fixes GitLab MCP: create_merge_request reports missing auth while identical PAT succeeds via REST API #32.

Test plan

  • npm run build succeeds locally (verified)
  • Smoke: stdio with GITLAB_TOKEN=glpat-... set, no per-call userCredentialscreate_merge_request succeeds (curl-equivalent behavior)
  • Smoke: HTTP with Authorization: Bearer <PAT>create_merge_request still succeeds (regression check for the per-session path)
  • Smoke: neither env token nor per-call creds — create_merge_request returns getClient()'s actionable error mentioning GITLAB_TOKEN
  • GITLAB_READ_TOKEN-only setups still reject writes (path unchanged in getClient())

Write tool handlers had an early-exit guard that required per-call
userCredentials, contradicting the documented design that GITLAB_TOKEN
is a full-access fallback usable for both reads and writes. The guard
fired before getClient() could resolve the env token, so stdio /
no-Authorization-header callers saw "User authentication is required..."
even with GITLAB_TOKEN configured. Reads were unaffected because read
handlers don't have the guard.

Removes the guard from create_issue, create_merge_request, update_issue,
delete_issue, update_merge_request, manage_pipeline, create_note,
delete_note, update_note, create_broadcast_message,
update_broadcast_message, delete_broadcast_message, and the
requiresWrite branch of execute_custom_query. getClient() already throws
an actionable error if no token at all is configured.

Fixes #32.
@ttpears ttpears merged commit 375b875 into main May 13, 2026
2 checks passed
@ttpears ttpears deleted the fix/write-tool-auth-fallback-32 branch May 13, 2026 03:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GitLab MCP: create_merge_request reports missing auth while identical PAT succeeds via REST API

1 participant