From 282ca6557d6426521465cc4d25167ded0edbbab5 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 10 Aug 2026 07:23:48 +0000 Subject: [PATCH] memory: session-scoped GraphQL block, and a safe issue_write method typo Record two learnings from UCD-SERG/serocalculator#661's ai-config follow-up (Morrison-Lab/ai-config#1389): - memories/github.md: a session's egress proxy can block GraphQL entirely (403, "only the pinned set of PR-review operations is served") even while gh api user / gh api repos// both return 200 over REST --- a second, distinct root cause for the check-pr-fully-clean.py failure already tracked in Morrison-Lab/ai-config#1330, alongside the pre-existing GraphQL rate-limit case. - memories/github-mcp-tools.md: issue_write's method enum only accepts "create" or "update" --- guessing "add_comment" fails loudly and safely (no data touched), distinct from the already-documented silent clobbering when method: "update" is called with just a comment string as body. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01NbqvD8bSKpeTjDwYpQSHeR --- memories/github-mcp-tools.md | 14 ++++++++++++++ memories/github.md | 30 ++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+) diff --git a/memories/github-mcp-tools.md b/memories/github-mcp-tools.md index 54a592ce..ac570b09 100644 --- a/memories/github-mcp-tools.md +++ b/memories/github-mcp-tools.md @@ -368,6 +368,20 @@ See ai-config#694 for the precedent. text as `body`, clobbering the freshly-filed issue description --- caught immediately from the echoed response and fixed with a restore-then-comment pair of calls.) +- **A milder, distinct mistake with the same tool: `issue_write`'s `method` + enum accepts only `"create"` or `"update"` --- there is no + `"add_comment"`.** + Guessing `method: "add_comment"` (a plausible name with no analog in the + real schema) fails loudly and immediately: `invalid method, must be + either 'create' or 'update'`. + No data is touched, unlike the silent clobbering above --- so this is a + safe failure mode, not a dangerous one, and the fix is simply to call + `add_issue_comment` instead. + Still worth naming so the two are not conflated: one fails loud and safe + at the call itself, the other succeeds and silently destroys prior + content. + (Hit while posting evidence to `Morrison-Lab/ai-config#1330`, 2026-08-10; + recovered with the correct tool on retry.) - **`mcp__github__create_or_update_file`'s `content` param is raw plain text, not base64** — despite the GitHub REST API's own `PUT /repos/.../contents/` endpoint taking base64, this MCP tool does the encoding for you. Passing an diff --git a/memories/github.md b/memories/github.md index 1a88a95d..56045cbd 100644 --- a/memories/github.md +++ b/memories/github.md @@ -55,6 +55,36 @@ The GitHub MCP tool surface used in remote/web sessions lives in with `graphql` at 4922/5000; the round's reply, thread-resolve, ARD summary, and clean-state verification all went through GraphQL, and `core` reset 11 minutes later.) +- **A session's egress proxy can block GraphQL entirely, as a session-scoped + policy rather than an account-level quota --- distinct from the rate-limit + case above, and easy to conflate with it.** + The symptom looks identical at first glance: `gh pr view --json ...` fails. + The cause is not shared. + `gh api rate_limit` reports a healthy `graphql` pool, and `gh auth status` + plus a plain `gh api ` both report success, so the session + reads as fully authenticated and REST-capable while every GraphQL call + fails identically: + ``` + HTTP 403: This GraphQL query is not enabled for this session --- only the + pinned set of PR-review operations is served. Use REST via + `gh api repos/{owner}/{repo}/...` instead. + ``` + Confirmed not scoped to one query: a minimal hand-written + `gh api graphql -f query='{ ... }'` against the same PR gets the identical + 403. + This breaks `scripts/check-pr-fully-clean.py` at its very first call + (`gh pr view --json ...` inside `get_pr_info()`), before anything + repo-specific runs, and the healthy `gh auth status`/REST readings make it + easy to misdiagnose as "something else is wrong" rather than "GraphQL is + closed here." + Route around it the same way as the rate-limit case: REST + (`gh api repos///pulls/` plus `.../commits` for the head SHA) or + the GitHub MCP tools, which already implement `pull_request_read` over + REST. + (`Morrison-Lab/ai-config#1330`, 2026-08-10, comment: this session's proxy + refused every GraphQL call while `gh api user`/`gh api repos//` both + returned 200 --- a second, distinct root cause for the same + `check-pr-fully-clean.py` failure symptom already tracked in that issue.) - **The @claude review bot's author name differs by API:** its comment author is `claude[bot]` in REST (`.user.login`) but `claude` in GraphQL (`.author.login`). A watcher filtering REST comments for `.user.login == "claude"` silently finds nothing — use `"claude[bot]"`. - **A third variant, and it is not one repo's quirk: the review comment can post as `github-actions[bot]` rather than `claude`/`claude[bot]`, and the