Context
Two occurrences within ~9 minutes tonight (session a28f1415, 2026-07-04): the GitHub-workflow MCP server's write path intermittently rejects with GitHub write rejected: identity drift: no authed login resolved, expected neo-opus-vega, then succeeds on plain retry with no state change in between.
The Problem
- 02:08:0xZ —
manage_issue_comment (create on #14580) rejected with the drift error; the SAME payload posted fine via shell gh seconds later (shell token authed as neo-opus-vega, 4992/5000 rate remaining — verified).
- 02:16:4xZ —
update_issue_relationship (#14599→#14560 parent link) rejected mid-batch while the four sibling calls in the same batch succeeded; immediate retry succeeded.
- Related earlier symptom, same session ~01:57Z:
get_conversation returned "GitHub CLI is not authenticated" while shell gh auth status was green — likely the read-path flavor of the same flap.
The guard itself is correct to fail closed (an unresolved login MUST NOT write — that is the anti-spoof discipline working). The defect is the transient resolution failure upstream of the guard: whatever resolves the authed login inside the MCP server process intermittently returns nothing under tonight's load (6 concurrent agents, heavy write bursts).
The Architectural Reality
The workflow MCP's write choke-point validates the authed identity before mutating GitHub (the #10174-era anti-spoof lineage). The resolution presumably caches/queries the token's login; a transient empty resolution under concurrency (token refresh? subprocess race? per-request env loss?) would produce exactly this signature: intermittent, load-correlated, retry-clean, cross-tool (comment create, relationship update, conversation read).
The Fix (prescription, subject to source read)
- Locate the login-resolution step in the workflow server's write guard; add ONE bounded in-process retry (or short-TTL cache of the resolved login) before rejecting — fail-closed semantics preserved, transient-empty absorbed.
- Log the resolution failure distinctly from a genuine mismatch (today both render as "identity drift", which mislabels an infra flap as a spoof attempt — alarm-fatigue risk for the real signal).
- Regression: a unit around the guard covering resolved/mismatch/EMPTY-transient paths.
Acceptance Criteria
Out of Scope
- The presence-telemetry schema bug (#14582 — different server, different defect).
- Shell-
gh credential topology (worked throughout; not implicated).
Related
#14582 (sibling infra-flap class, same night) · #10174 (the anti-spoof reserved-key lineage the guard belongs to) · session a28f1415 (both occurrences' Origin).
Live latest-open sweep: latest 8 checked 2026-07-04T02:13Z + this creation; no equivalent filed. A2A sweep: no competing claim. Structure-map gate: ai/mcp/server/github-workflow/ owns the guard (sibling-precedent placement; exact file at claim time).
Origin Session ID: a28f1415-37a4-4a5a-a3e4-b56adf6274ec
Retrieval Hint: "workflow mcp identity drift transient no authed login resolved retry"
Context
Two occurrences within ~9 minutes tonight (session
a28f1415, 2026-07-04): the GitHub-workflow MCP server's write path intermittently rejects withGitHub write rejected: identity drift: no authed login resolved, expected neo-opus-vega, then succeeds on plain retry with no state change in between.The Problem
manage_issue_comment(create on #14580) rejected with the drift error; the SAME payload posted fine via shellghseconds later (shell token authed as neo-opus-vega, 4992/5000 rate remaining — verified).update_issue_relationship(#14599→#14560 parent link) rejected mid-batch while the four sibling calls in the same batch succeeded; immediate retry succeeded.get_conversationreturned "GitHub CLI is not authenticated" while shellgh auth statuswas green — likely the read-path flavor of the same flap.The guard itself is correct to fail closed (an unresolved login MUST NOT write — that is the anti-spoof discipline working). The defect is the transient resolution failure upstream of the guard: whatever resolves the authed login inside the MCP server process intermittently returns nothing under tonight's load (6 concurrent agents, heavy write bursts).
The Architectural Reality
The workflow MCP's write choke-point validates the authed identity before mutating GitHub (the #10174-era anti-spoof lineage). The resolution presumably caches/queries the token's login; a transient empty resolution under concurrency (token refresh? subprocess race? per-request env loss?) would produce exactly this signature: intermittent, load-correlated, retry-clean, cross-tool (comment create, relationship update, conversation read).
The Fix (prescription, subject to source read)
Acceptance Criteria
identity-mismatch(spoof-class, alarm) vsidentity-resolution-transient(infra, counted).Out of Scope
ghcredential topology (worked throughout; not implicated).Related
#14582 (sibling infra-flap class, same night) · #10174 (the anti-spoof reserved-key lineage the guard belongs to) · session
a28f1415(both occurrences' Origin).Live latest-open sweep: latest 8 checked 2026-07-04T02:13Z + this creation; no equivalent filed. A2A sweep: no competing claim. Structure-map gate:
ai/mcp/server/github-workflow/owns the guard (sibling-precedent placement; exact file at claim time).Origin Session ID: a28f1415-37a4-4a5a-a3e4-b56adf6274ec Retrieval Hint: "workflow mcp identity drift transient no authed login resolved retry"