Context
The github-workflow MCP create_issue tool failed once (2026-06-15, GitHub CLI is not authenticated) while, in the same session, (a) Bash gh was fully authenticated and (b) the API-based sibling MCP tools (manage_pr_review, manage_issue_comment, update_issue_relationship, …) all worked.
Root cause (corrected)
Source-verified divergence: IssueService.createIssue (IssueService.mjs:519) runs a fresh spawn('gh', ['issue','create',…]) per call — re-resolving gh-auth every invocation. The API siblings route through GraphqlService.#getAuthToken (GraphqlService.mjs:91), which shells gh auth token once, caches it (#authToken), then uses fetch() — insulated from later gh hiccups after the first token fetch. The manage_issue_assignees paths (execAsync('gh issue edit …'), IssueService.mjs:227/267/1103) share the per-call gh-shell exposure.
⚠️ The mechanism of the single failure is NOT reproduced — I won't assert why the fresh spawn failed auth that once (transient gh blip vs spawn-env difference) without a repro. The earlier "spawn inherits process.env which lacks GH_TOKEN" framing was a grep-deep / verify-shallow over-claim (both paths root on gh; gh WAS authed) and is retracted — see the correction comment.
Proposed fix (mechanism-independent)
Route createIssue (+ the gh issue edit assignee paths) through GraphqlService's cached-token, retry-equipped API path (already has #getRetryDelay transient-failure retry) — unifying on the single auth path the working tools use and removing the per-call fresh-gh-auth exposure. Defensible on consistency/robustness grounds regardless of the one failure's exact mechanism.
Impact
Moderate DX friction: a create_issue failure forces the gh issue create Bash workaround, which bypasses MCP sync / labeling / project-chaining. Observed once (filed sibling #13343 via the workaround). Reproducibility unconfirmed → lower severity if a one-off; the auth-path-unification robustness fix applies either way.
Authored by Claude Opus 4.8 (Claude Code), @neo-opus-vega (Vega).
Context
The github-workflow MCP
create_issuetool failed once (2026-06-15,GitHub CLI is not authenticated) while, in the same session, (a) Bashghwas fully authenticated and (b) the API-based sibling MCP tools (manage_pr_review,manage_issue_comment,update_issue_relationship, …) all worked.Root cause (corrected)
Source-verified divergence:
IssueService.createIssue(IssueService.mjs:519) runs a freshspawn('gh', ['issue','create',…])per call — re-resolving gh-auth every invocation. The API siblings route throughGraphqlService.#getAuthToken(GraphqlService.mjs:91), which shellsgh auth tokenonce, caches it (#authToken), then usesfetch()— insulated from laterghhiccups after the first token fetch. Themanage_issue_assigneespaths (execAsync('gh issue edit …'),IssueService.mjs:227/267/1103) share the per-call gh-shell exposure.⚠️ The mechanism of the single failure is NOT reproduced — I won't assert why the fresh spawn failed auth that once (transient
ghblip vs spawn-env difference) without a repro. The earlier "spawn inheritsprocess.envwhich lacksGH_TOKEN" framing was a grep-deep / verify-shallow over-claim (both paths root ongh; gh WAS authed) and is retracted — see the correction comment.Proposed fix (mechanism-independent)
Route
createIssue(+ thegh issue editassignee paths) throughGraphqlService's cached-token, retry-equipped API path (already has#getRetryDelaytransient-failure retry) — unifying on the single auth path the working tools use and removing the per-call fresh-gh-auth exposure. Defensible on consistency/robustness grounds regardless of the one failure's exact mechanism.Impact
Moderate DX friction: a
create_issuefailure forces thegh issue createBash workaround, which bypasses MCP sync / labeling / project-chaining. Observed once (filed sibling #13343 via the workaround). Reproducibility unconfirmed → lower severity if a one-off; the auth-path-unification robustness fix applies either way.Authored by Claude Opus 4.8 (Claude Code), @neo-opus-vega (Vega).