[Bug] `/doctor` misdiagnoses keychain authorization as locked/corrupt in daemon context

Bug Description

/doctor keychain check misdiagnoses cause and suggests a harmful fix when run

under claude agents

Version: claude 2.1.183
Platform: macOS (Darwin 25.5.0), Apple Silicon
Auth: Claude subscription (OAuth; credential Claude Code-credentials in
login.keychain)

### Summary
When /doctor runs inside the claude agents background daemon, its keychain
write-probe fails and it reports the login keychain as "not writable", then
recommends unlocking the keychain and changing the login keychain password.
Both are wrong for this situation and the password suggestion is potentially
harmful: the keychain was healthy and writable the entire time from the GUI
session. The real cause is that the agents daemon runs detached from the macOS
GUI (Aqua) security session, so it lacks keychain write authorisation — nothing
to do with the keychain being locked or its password being out of sync.

### What /doctor reported
> macOS Keychain is not writable (security: SecKeychainSearchCreateFromAttributes:
> One or more parameters passed to a function were not valid.; security:
> SecKeychainItemCreateFromContent (<default>): Unable to obtain authorization for
> this operation.; add-generic-password: [REDACTED] -60008). Console login will fail
> to save your API key.
> Suggested fix: Run: security unlock-keychain
~/Library/Keychains/login.keychain-db
> — if that doesn't fix it ... open Keychain Access ... Edit → Change Password for
> Keychain 'login'.

-60008 is errAuthorizationInternal — an authorisation-session failure, not a
locked/corrupt keychain. Following the suggested "change login keychain password"
step would be disruptive (affects all of macOS) and would not help.

### Why it's wrong

• security show-keychain-info login.keychain-db → no-timeout (unlocked).
• The Claude Code-credentials item exists and was written/refreshed minutes
• Interactive claude (same user, same machine) reads/writes the keychain fine.
• The failing process is the agents daemon: `claude daemon run --origin

transient, reparented to PID 1, i.e. outside the GUI security session — which
is exactly what produces errAuthorizationInternal` on keychain writes.

So /doctor is probing keychain writability from a context that structurally
can't write it, then attributing the failure to keychain health.

### Repro

1. Start claude agents (spawns the transient daemon).
2. Toggle/disable some MCP servers from within the agents view (this wedged the

daemon into the no-keychain-write state in my case).

1. Run /doctor from the agents context → keychain reported "not writable" with

the unlock/change-password suggestion.

1. Run /doctor from interactive claude in a GUI terminal → keychain is fine.

Resolved by claude daemon stop --any + relaunching claude agents from a
keychain-capable terminal. No keychain changes were needed.

### Suggested fixes

1. Detect the non-GUI/daemon security-session context and either skip the

keychain-write probe or report it accurately ("running outside the GUI
security session; keychain writes unavailable here — log in via interactive
claude") instead of "keychain not writable / change your password".

1. Distinguish errAuthorization* (session/authorisation) from

errSecNoSuchKeychain/locked-keychain codes and only suggest unlock/
change-password for the latter.

### Secondary (lower priority, context only)

• The daemon lost keychain-write access after an in-session MCP-server toggle —

may be worth hardening, but harder to reproduce.

• After upgrading 2.1.181 → 2.1.183, stale 2.1.181 bg-pty-host worker

processes were left orphaned to PID 1; claude daemon stop --any did not reap
them (they predated the running daemon). Minor cleanup gap on upgrade.

Environment Info

• Platform: darwin
• Terminal: kitty
• Version: 2.1.183
• Feedback ID: 719d7950-9e9c-4f9a-9b7a-a284a000747e

Errors

[]