[BUG] Desktop global "Auto-fix CI and address comments" toggle never applies to PRs created via gh from local sessions, and doesn't persist in claude_desktop_config.json

I am experiencing the same problem, and stumbled on this issue while debugging. It looks like a configuration could be missing?

Still reproducing on current versions, and I think I can sharpen the second half of this report: the toggle state does persist — just per-PR, inside per-session files — and nothing ever seeds it from the global setting.

Environment

• Claude Code 2.1.217
• Claude Desktop 1.24012.9
• macOS 26.5.2 (build 25F84, Darwin 25.5.0)
• Global Settings → Pull requests → "Autofix pull requests": ON

Where the state actually lives

There is no autofix-ish key in any global config — I grepped ~/Library/Application Support/Claude/config.json, ~/Library/Application Support/Claude/claude_desktop_config.json (only keys: coworkUserFilesPath, preferences), ~/.claude.json, and ~/.claude/settings.json. Zero hits, confirming the persistence half of this report.

The effective state is written per-PR here:

~/Library/Application Support/Claude/claude-code-sessions/<user>/<project>/local_<session-uuid>.json
  └─ prs[] → { autoFix, baseRef, branch, host, prNumber, repo, state, url }

prs[].autoFix is only written when you tick the per-PR "Auto-fix CI & address comments" checkbox in the CI-monitoring popover. Otherwise the key is simply absent, and the PR behaves as opt-out — regardless of the global setting.

Quantified over my local session store

50 session files, 21 of which have a non-empty prs[], 34 tracked PR entries total — with the global setting ON the whole time:

| prs[].autoFix | count |
|---|---|
| true (I ticked the box by hand) | 9 |
| false | 1 |
| key absent | 24 |

So ~70% of PRs the app was actively tracking got no autofix subscription.

Why this isn't just "the setting was enabled recently"

The states are interleaved within single sessions at identical timestamps, which I think rules out any ordering explanation:

session-file mtime   PR          autoFix
2026-07-29 08:49     repo-d#4    true
2026-07-29 08:49     repo-c#14   true
2026-07-29 08:49     repo-c#16   ABSENT     <-- same session, same minute
...
2026-07-29 11:57     repo-b#46   true
2026-07-29 12:00     repo-a#106  ABSENT
2026-07-29 12:16     repo-a#104  true
2026-07-29 12:16     repo-a#107  true
2026-07-29 12:16     repo-e#5    ABSENT     <-- same session, same minute
2026-07-29 12:16     repo-e#6    true

Same global setting state, same instant, different results — the only variable is whether I happened to click the checkbox. (Repo names redacted; these are private repos.)

That last pair is also consistent with #65488 — within one session, some PR entries in prs[] get subscribed and others don't.

Repro script

Run with the global setting ON, after a few sessions have created PRs via gh pr create:

python3 - <<'EOF'
import json, glob, os
root = os.path.expanduser("~/Library/Application Support/Claude/claude-code-sessions")
t = f = absent = 0
for p in glob.glob(os.path.join(root, "**", "*.json"), recursive=True):
    try: d = json.load(open(p))
    except Exception: continue
    if not isinstance(d, dict): continue
    for e in d.get("prs") or []:
        if not isinstance(e, dict): continue
        if "autoFix" not in e: absent += 1
        elif e["autoFix"] is True: t += 1
        else: f += 1
print(f"autoFix true={t} false={f} absent={absent}")
EOF

Expected if the global setting were honored: absent=0. Observed: absent dominates.

Impact

The per-PR checkbox is the only thing that works, so it has to be clicked on every single PR — which defeats the purpose of a global default. For anyone running a scripted ship flow (gh pr create from a local session, one PR per worktree), that's a manual click per PR, and it's easy to miss and then wonder why nothing is being monitored.

Suggested fix

Seed prs[].autoFix from the global setting at the point a PR entry is added to prs[], rather than leaving the key unset until a manual click. If the global setting is genuinely intended to be remote-sessions-only, the settings copy should say so the way the sibling "Create pull requests automatically" setting does ("Applies to remote sessions only") — and the per-PR checkbox should probably still inherit it.

Worth noting the related #52474 (closed as not planned) reports that even after ticking the box, GitHub events aren't delivered into local sessions — particularly worktree sessions. If that's still current, then fixing the default alone won't be sufficient.

Additional cross-platform reproduction, Windows desktop app:

Worked a long single desktop session across 4 sequential PRs on the same repo, all created via gh pr create from a local Bash tool call (not the desktop app's own PR-creation UI): #421 → #428 → #436 → #448. "Auto-fix pull requests" ci-monitor-events (CI failures, new review comments) arrived automatically and correctly for at least two of these PRs mid-session without the toggle being touched between them, so per-PR monitoring clearly can get armed for a gh-created PR in this environment -- but it didn't happen consistently for every PR in the sequence, and there was no way from inside the session to tell in advance whether a freshly-opened PR would get picked up or not.

That's consistent with this report's second comment (state persists per-PR in session files, nothing seeds it from a global setting) rather than "never works for gh-created PRs at all" -- in my case it worked, intermittently, for a gh-created PR in the same session as prior ones, which points more at a seeding/re-subscription gap than a hard gh pr create exclusion.

Environment: Claude Desktop (Windows 11), same repo (Damont14/magnetar) for all 4 PRs, all within one continuous session.