Claude Code desktop: "Auto-fix CI & address comments" doesn't dispatch to local session

Summary

The "Auto-fix CI & address comments" toggle in the Claude Code desktop app is silently failing across the board. No GitHub events of any kind are being delivered to local Claude Code sessions — not CI failures, not review comments, not check-suite transitions, not bot reviews, not human reviews. The local session sits idle with zero events in context until a user manually prompts it.

This has been the behavior across multiple PRs and multiple reviewers (CodeRabbit, Gemini code-assist, GitHub Actions status checks). The feature is functionally dormant.

Environment

• Claude Code version: 2.1.118
• Surface: Claude Code desktop app (macOS, Darwin 25.4.0)
• Session context: running inside a git worktree (.claude/worktrees/...)
• Desktop toggle: "Auto-fix CI & address comments" enabled throughout
• PR flow: PR created from the local session via gh pr create

Expected behavior

With "Auto-fix CI & address comments" enabled, the desktop app should deliver GitHub events for PRs I've created to the local Claude Code session that created them, so the session can automatically address review comments and fix failing CI. This is the documented value prop of the toggle, and it's distinct from the web-based /autofix-pr slash command.

Actual behavior

Zero GitHub events are delivered to the local session. I verified this by asking the assistant, from within an active session, whether it had received any GitHub events since the PR was created — it confirmed none were ever pushed to its context. Every status update the assistant could give came from it manually running gh CLI commands on demand.

This holds regardless of:

• Event type (CI check conclusions, review submissions, inline review comments, PR comments, re-reviews).
• Reviewer identity (CodeRabbit, gemini-code-assist[bot], GitHub Actions, human reviewers).
• Review state (COMMENTED, CHANGES_REQUESTED, APPROVED).
• Check conclusion (success, failure, skipped).

One concrete repro (PR #4163 in a private repo)

1. T=0 — local Claude Code session (in a git worktree) creates a PR via gh pr create.
2. T+2min — gemini-code-assist[bot] posts an inline review with state COMMENTED and a concrete code suggestion.
3. T+2min — coderabbitai posts a top-level PR comment.
4. T+2min — GitHub Actions CI runs finish (lint-and-analyze SUCCESS, label SUCCESS, CodeRabbit SUCCESS; gate/automerge/autofix SKIPPED).
5. T+2..29min — none of the above events reach the local session; nothing appears in context, nothing in the desktop app's activity/notification surface indicates a session was dispatched.
6. T+29min — user manually prompts "fix the PR review comments"; assistant addresses the review and pushes a second commit.
7. T+29..60min+ — no post-fix events delivered either (no re-review detection, no check re-run notification).

Hypotheses (any could apply — a log surface would confirm which)

• Webhook never reaches the desktop app. Delivery from GitHub → Anthropic endpoint → desktop is broken or not wired up.
• Desktop app receives events but can't route them to a session. Possible causes:
• Worktree sessions (.claude/worktrees/...) aren't in the routing table.
• Sessions aren't reliably associated with the PRs they created.
• The app only routes to "active" sessions and silently drops events when the session is idle/backgrounded.
• Reviewer/event allowlist is so narrow that nothing qualifies in practice.
• Silent CodeRabbit short-circuit: if CodeRabbit posts "No actionable comments," all other events on that PR are suppressed.

What would help

1. An event log / activity panel in the desktop app showing every GitHub event received per PR and the dispatch decision (delivered to session X / filtered by rule Y / dropped because Z). Without this, users can't tell if the feature is working, misconfigured, or broken.
2. Docs on the routing rules — reviewer allowlist, event-type filter, review-state filter, worktree eligibility, active-session requirement. Current docs describe the toggle at a high level but don't explain the filter surface, so there's no way to verify your setup is expected to work.
3. A self-test command (e.g. a "test-dispatch" button or CLI) that simulates a synthetic event and confirms end-to-end delivery to the local session. This would be diagnostic gold.
4. Visible failure notification. If an event is received but not dispatched, the desktop app should surface that instead of silently dropping it.

Happy to share specific PR URLs privately if useful for debugging.