bug: responder agent cannot read PR review threads — MCP returns empty, curl not attempted

[microsasa]

Problem

The responder agent fails to read review comment threads. The MCP pull_request_read tool returns [] for every method (get, get_review_comments, get_reviews, get_diff, get_files). The agent tries MCP 10+ times, gets empty results, and gives up — reporting missing_data instead of addressing comments. It never falls back to curl despite the instructions telling it to use the REST API.

Timeline (2026-03-20)

Working runs:

• 06:12 — Responder run 23331383724 on PR fix: add fast pre-filter to session command to avoid O(n) full parse (#138) #171. Successfully read 3 threads, fixed code, replied to all 3, pushed. Agent used --allow-all-tools --allow-all-paths. Output types: add_labels, reply_to_pull_request_review_comment, push_to_pull_request_branch.
• 06:20 — Responder run 23331578055 on PR fix: render_live_sessions shows active fields for resumed sessions (#139) #172 round 1. Successfully read 1 thread, fixed code, replied, pushed.

Failed runs (same config, same lock file, same network):

• 07:08 — Responder run 23332736595 on PR fix: render_live_sessions shows active fields for resumed sessions (#139) #172 round 2. MCP returned []. Agent reported missing_data: "Cannot read review comments. The pull_request_read MCP tool returns [] for all methods." Output types: add_labels, missing_data. Duration: 17s.
• 07:25 — Responder run 23333161332 on PR fix: render_live_sessions shows active fields for resumed sessions (#139) #172 round 3. Same failure. Duration: 17s.
• 07:32 — Responder run 23333327590 on PR fix: render_live_sessions shows active fields for resumed sessions (#139) #172. Same failure. Duration: 17s.
• 08:12 — Responder run 23334483446 on PR fix: populate active_* fields for pure active sessions (#154) #177. MCP returned [] for 10+ attempts. Agent tried pull_request_read repeatedly, then issue_read, then search_pull_requests (which worked but doesnt return thread content). Never tried curl. Duration: 2m 16s. Output types: add_labels, noop.

Verification: PR #177 confirmed to have 4 unresolved review threads via our local MCP tools (outside the agent sandbox) at the same time the agent was failing.

What did NOT change between working and failing runs

• Responder .md file: identical (no commits touched it)
• Responder .lock.yml: identical
• Agent flags: --allow-all-tools --allow-all-paths in both
• Network domains: identical (including api.github.com)
• Safe output config: identical (target: "*" for reply and push)
• gh-aw version: v0.60.0 in both

What DID change

Nothing in the responder config. The only merges between working and failing runs were:

• PR fix: quality gate review approval + cron enable #174 (quality gate + cron) — touched quality-gate.md, quality-gate.lock.yml, pipeline-orchestrator.yml, docs
• PR fix: add fast pre-filter to session command to avoid O(n) full parse (#138) #171 merge (aw PR for issue [aw][code health] session command does O(n) full parse to find one session by ID prefix #138) — touched cli.py, test_cli.py

None of these touched responder files.

Key observations

1. MCP pull_request_read works outside the agent sandbox (we can read threads fine from local CLI)
2. MCP pull_request_read worked inside the sandbox at 06:12 and 06:20
3. MCP pull_request_read stopped working inside the sandbox at 07:08 and all subsequent runs
4. The agent has instructions to use curl with REST API but does not attempt it
5. The agent has --allow-all-tools so curl is available
6. search_pull_requests MCP tool works inside the sandbox (agent found PR fix: populate active_* fields for pure active sessions (#154) #177 via search)
7. list_pull_requests MCP tool works inside the sandbox

Impact

The responder is completely broken. PRs with review comments cannot be addressed autonomously. Three PRs are now stuck (#171, #172 with aw-pr-stuck:review, #177 with unaddressed comments).

Possible root causes to investigate

1. MCP server state/caching issue inside the sandbox
2. GitHub API token scope change or rate limiting inside the sandbox
3. gh-aw MCP gateway routing issue for pull_request_read specifically
4. Something about the PR state (e.g., rebased commits, force-pushed) that causes MCP to return empty

Related

• tracking: upgrade gh-aw MCP server to get real thread IDs for review-responder #114 (MCP server thread ID limitation — different issue but same MCP server)
• [aw] Review Responder failed #153 (previous responder failure — may be same root cause)
• Audit all gh-aw workflows against official documentation and samples #173 (gh-aw audit — should investigate MCP reliability)