[BUG] Claude Desktop (macOS): instances quit silently — clean beforeQuit, no crash report, not memory, active window always survives

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

NOTE: This is a Claude Desktop bug, not Claude Code CLI. Filing here per the guidance that Desktop issues belong in this repo with the `external` label.

I run multiple Claude Desktop windows as my normal workflow (3-4 at a time). Windows quit themselves with no error, no crash dialog and no warning — the window simply disappears.

The consistent pattern: it is almost always a window I am NOT actively typing in. The window with focus survives; idle ones die. 17 quit events in a single day.

Environment:
- Claude Desktop 1.24012.9
- macOS 26.5 (25F71)
- MacBook Pro M3 Pro, 18GB RAM

Instance lifetimes are inconsistent, so it does not appear to be a fixed timer:

```
launched 17:47 -> quit 17:51 (~3.5 min)
launched 18:00 -> quit 18:03 (~2.5 min)
launched 18:04 -> quit 18:20 (~16 min)
```

### What Should Happen?

Instances should stay open until the user closes them.

If the app is deliberately terminating an instance, the reason should be logged. At present `main.log` records a full graceful shutdown with no preceding entry indicating any trigger, which makes this impossible to diagnose or work around.

### Error Messages/Logs

```shell
Every quit is a clean, deliberate shutdown — not a crash:

18:23:54 [info] Successfully run onQuitCleanup: cowork-vm-shutdown
18:23:54 [info] Successully ran all onQuitCleanup handlers, marking readyForQuit
18:23:54 [info] beforeQuit: handler fired, going down
18:23:54 [info] beforeQuit: handler is ready for quit, so quitting
18:23:54 [info] [EventLogging] Flushing 1 events
18:23:54 [info] willQuit: handler fired, going down
18:23:54 [info] willQuit: handler is ready for quit, so quitting

All cleanup handlers run, exit code 0. Nothing is logged in the 20+ seconds beforehand — no error, no warning, no trigger. Silence, then shutdown.

Memory reading from the app's own telemetry at the last quit:
tree_rss_sum=1286MB sys_free=... sys_free_raw=1784MB

1.7GB genuinely free, zero swap in use.

Also seen with multiple instances open:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 listeners added to [EventEmitter]
...claude.settings_$_AppPreferences
...claude.web_$_AutoUpdater_$_updaterState
...claude.web_$_LocalAgentModeSessions
```

### Steps to Reproduce

1. Open Claude Desktop normally
2. Open additional instances from Terminal: `open -n -a Claude` (repeat for 3-4 total)
3. Work in one window and leave the others idle
4. Within a few minutes one or more idle windows quits itself, with no warning or error shown
5. Check `~/Library/Logs/Claude/main.log` — a clean `beforeQuit` / `willQuit` / `onQuitCleanup` sequence with exit code 0
6. Check `~/Library/Logs/DiagnosticReports` — no crash report and no jetsam report exists
7. Check `~/Library/Application Support/Claude/Crashpad/pending` — empty

Happens on a fresh boot with several GB free and zero swap in use.

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

Claude Desktop 1.24012.9 (CCD 2.1.219) — not Claude Code CLI

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

**What I ruled out**

- **Not a crash.** Zero entries in `~/Library/Logs/DiagnosticReports`. Crashpad `pending` folder empty.
- **Not an OOM kill.** No jetsam reports. Last quit occurred with 1.7GB free and zero swap.
- **Not general memory pressure.** Removed ~2GB of other apps and rebooted after 33 days uptime. Swap went to zero, wired memory dropped from 2.97GB to 1.76GB. Quits continued.
- **Not a stale bridge session.** Found `bridge-state.json` pinning a dead `remoteSessionId`, retrying and failing 68 times in 45 minutes (`Transport permanently closed code=4090`, `AcknowledgeWork: Conflict (409): Work item must be in QUEUED state`). Deleting the file took transport failures to zero and instances survived noticeably longer — but quits still occur.
- **Not user-initiated.** Individual windows die while others stay open, so a global quit action cannot explain it.
- **Not a modified install.** Single `Claude.app`, signed by Anthropic (TeamIdentifier Q6L2SF6YDW).

**Related observations**

- `[WarmLifecycle:cowork] Initialized (arm=always)` fires on every launch. The Cowork VM starts whether or not Cowork is used, sits at 1.1-1.9GB and grows through the day. There is no user-facing way to disable it on an individual plan — the only toggle is org-level (Team/Enterprise).
- `trigger=stall` fires on every newly launched instance.
- All instances write to a single shared `main.log`, which makes attributing a quit to a specific instance impossible.

**Requests**

1. Log the reason an instance quits — there is currently nothing actionable.
2. Provide a way to disable the Cowork VM on individual plans for users who don't use Cowork.
3. Clarify whether multiple instances are a supported configuration.

**Possibly related but not a duplicate:** #23092 (SessionIdleManager 300s idle quit). I checked — `SessionIdleManager`, `lam_vm_shutdown_completed` and `was_killed` do **not** appear anywhere in my logs, and my instance lifetimes are inconsistent rather than a fixed 300s. Likely a different mechanism.

Happy to provide the full `main.log` on request.

Start by reproducing the multi-instance behavior with `open -n -a Claude`, then inspect `~/Library/Logs/Claude/main.log`, DiagnosticReports, and Crashpad/pending for a per-instance quit trigger. Compare the clean `beforeQuit`/`willQuit` sequence and the reported `SessionIdleManager` and Cowork observations. Done means identifying the termination cause and making the reason actionable in logs, while clarifying whether multiple instances are supported.

Written by the indexing model from the issue text.