[BUG] Desktop: project thread's PR bar shows Auto-fix CI unchecked while its Remote Control session's local monitor is on

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

In the Claude desktop app on macOS, a claude.ai project thread can run on the Mac through Remote Control. The app creates a local Code session for it. When Claude in that session opens a GitHub PR and turns on Auto-fix with mcp__ccd_pr__set_monitor, the local monitor is really on: get_status reports auto_fix: true, and the app wakes the session on new review comments.

But when the user opens that thread in the project view and clicks the PR bar's CI menu, the CI monitoring popover shows Auto-fix CI & address comments unchecked. The popover's check counts are current (they match get_status at the same moment), so it is reading the right PR, just not the Auto-fix state of the local session that runs the thread.

As a result, the thread tells the user "CI auto-fix is on", and the place the user checks says it is off. The user reasonably reads the thread as wrong.

What Should Happen?

The project thread's PR bar should show the Auto-fix state of the local session that runs the thread, or both views should share one switch. Ticking the box in the thread view should not start a second, competing monitor for a PR the local session already watches.

Error Messages/Logs

# set_monitor result in the session
Auto-fix is on for <owner>/<repo>#<n>: the app will wake this session with a `<ci-monitor-event>` on CI failures, merge conflicts and new review comments. No need to poll CI.

# get_status right after, and still several minutes later
"monitor": { "auto_fix": true, "address_comments": true, "auto_merge": false, "auto_archive_on_close": false }

# ~/Library/Logs/Claude/main.log
[info] [AutoFixEngine] new auto-fix target on local_<id>; kicking sweep
[info] [AutoFixEngine] Waking local_<id>: 0 failure(s) + 1 comment(s)

# When the project thread view with the PR bar is opened, polling for that PR starts with an empty cwd
[info] LocalSessions.getPrReviewComments: cwd=, prNumber=<n>, repo=<owner>/<repo>

Steps to Reproduce

1. In a claude.ai project with Remote Control serving a folder on your Mac, start a thread so it runs on the Mac. The desktop app creates a local Code session in a worktree.
2. In that thread, have Claude open a GitHub PR, then call mcp__ccd_pr__get_status (shows auto_fix: false) and mcp__ccd_pr__set_monitor with {"auto_fix": true, "address_comments": true, "url": "<pr url>"}.
3. Confirm get_status now reports auto_fix: true and main.log shows [AutoFixEngine] new auto-fix target on local_<id>. Leave a review comment on the PR; the session is woken.
4. In the desktop app, open the project and the thread, then click CI on the PR bar under the thread.
5. The popover shows current check counts, but Auto-fix CI & address comments is unchecked.

Five such threads had the local monitor on for their PRs the same day; the thread view above was checked on one of them.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.288 (bundled with Claude desktop 2.19675.1)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (Claude desktop app)

Additional Information

From the installed bundle, Auto-fix state lives in the local session record (prs[].autoFix) and the local AutoFixEngine. I found no path that sends it over the Remote Control bridge (the bridge's reportMetadata is never called with PR or Auto-fix state). So my guess is that the thread view reads the bridged remote session's switch while the local session holds the real one. That cause is inferred, not confirmed.

A Remote Control session's tools cannot read or set the thread view's switch: set_monitor only reaches "this session's" local monitor.

Related but different: #90751 (checkboxes reset per PR) and #90356 (checkbox no-ops for PRs created outside the app). Here the local monitor is on and working, and only the project thread view shows it off.