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

Additional context on the regression question.

This began after Cowork was integrated into the main desktop app. Before that I ran 3-4 instances routinely as my standard workflow with no instability at all. I can't pin an exact version number, but the change in behaviour tracks with that integration rather than with any change on my machine.

claude-main.log

Two things that may help narrow it down:

The Cowork VM is armed on every launch regardless of use. [WarmLifecycle:cowork] Initialized (arm=always) appears at every startup. I have never opened Cowork in these sessions. The VM process sits at 1.1-1.9GB and grows over the course of a day. With no way to disable it on an individual plan, every extra instance carries that cost whether the feature is wanted or not.

Instances that stay focused survive indefinitely. One instance in my logs ran for over three hours without issue while others launched alongside it died within minutes. That asymmetry seems like the most useful clue — whatever terminates them appears to discriminate by activity or focus, but nothing in main.log records the decision.

Happy to run any diagnostic that would help, or to provide the full log for the day (13:03-18:30, 17 quit events).

Useful for anyone else debugging this: DESKTOP_LOG_LEVEL=debug unlocks far more diagnostic output

From index.chunk-CnWKsyE_.js:

const u1e = process.env.DESKTOP_LOG_LEVEL ?? (app.isPackaged ? "info" : "debug")

Launching the binary directly with the variable set turns on debug logging in packaged builds:

DESKTOP_LOG_LEVEL=debug /Applications/Claude.app/Contents/MacOS/Claude

This adds several hundred debug lines to main.log, including a full dump of every GrowthBook feature gate with its resolved state (466 gates in my case, in the form [growthbook] <id>: on=true|false value=... source=...). That makes it possible to check whether a given feature is actually enabled for your account rather than guessing.

A candidate I was able to rule out with it:

app.asar contains a stealth auto-update scheduler (scheduleRestartWhenIdle, class with const w7e=600*1e3) whose logic matches this bug's symptom closely — idleBlocker() returns "window focused" and reportWindowFocus() cancels the countdown, so a focused window would never be restarted while blurred ones would be quit and reinstalled after 10 minutes. There is also a [stealth-relaunch] path that saves navigation history to a marker file before app.quit().

It is gated behind 3691521536. With debug logging on, my dump shows:

[growthbook]   3691521536: on=false value=false source=defaultValue

So stealth update is not the cause here — at least not for my account. Recording it so nobody else spends time on the same lead.

Suggestion for the app: whatever terminates an instance should log the reason at info level. main.log currently records a complete beforeQuit → onQuitCleanup → willQuit sequence with no preceding entry explaining the trigger, which makes this effectively undiagnosable from the outside. A single line naming the caller would have resolved this in seconds.

I now have an instance running with DESKTOP_LOG_LEVEL=debug and will post the debug output from the next quit.

Update after 24 hours of monitoring — this looks like singleton contention between instances, not resources. Reproducible at exactly the third instance.

I ran a monitor overnight sampling every 2 minutes. New findings:

Memory is conclusively ruled out

Two instances ran continuously for 13h50m and 13h43m overnight. During that window sys_free_raw repeatedly dipped as low as 70MB (samples at 0.07GB, 0.10GB, 0.11GB, 0.13GB). Neither instance quit. If low memory triggered these quits, they would have died many times over.

The failure is deterministic at the third instance

Two instances: stable indefinitely. Launch a third and something quits within ~10 seconds:

09:52:41  Starting app        (3rd instance)
09:52:51  beforeQuit          <- 10s later
09:53:51  beforeQuit
09:53:52  Starting app
09:59:02  beforeQuit
10:00:03  beforeQuit + Starting app

Memory at those quits: sys_free_raw=766MB and sys_free_raw=272MB. Not exhaustion.

What the third instance's startup actually does

This is the part that looks like the bug. During the third instance's initialisation:

[Restore] Skipping local_5577450a-745d-4da2-b583-c77e3dd08990 — live session already in memory
[Restore] Skipping local_61c62b5c-b03f-4e70-b9f1-ee24d00e7aa7 — live session already in memory
[Restore] Skipping local_4b985e03-f4d8-4c89-aaa0-b599ebe6f42b — live session already in memory
   ... ~25 further sessions skipped, same reason ...
[warn] [ScheduledTasks] Already initialized
[info] [LocalAgentModeSessionManager] Scheduled tasks service initialized
[info] [WarmLifecycle:cowork] Destroyed          <- during another instance's launch
[info] [ScheduledTasks] Reset

So a newly launching instance:

1. Finds ~25 local agent sessions already live and declines to restore them
2. Hits [ScheduledTasks] Already initialized — a shared service it cannot claim
3. Destroys the Cowork warm VM and resets ScheduledTasks, which the already-running instances are using

Then, seconds later, an instance quits.

Together with the previously reported MaxListenersExceededWarning: 11 listeners on AppPreferences, AutoUpdater updaterState and LocalAgentModeSessions, and the fact that all instances write to one shared main.log, the picture is that session state, scheduled tasks and the Cowork VM are effectively process-global singletons. Two instances tolerate sharing them. A third cannot initialise without tearing down state the others depend on, and one of them exits.

This would explain why the quit is always graceful with no logged reason — from the quitting instance's perspective nothing failed. It would also explain why this began when Cowork was integrated, since the shared VM and the session manager arrived with it.

Useful diagnostic for anyone reproducing this

DESKTOP_LOG_LEVEL is read at startup and overrides the packaged default of info:

const u1e = process.env.DESKTOP_LOG_LEVEL ?? (app.isPackaged ? "info" : "debug")

DESKTOP_LOG_LEVEL=debug /Applications/Claude.app/Contents/MacOS/Claude

That adds several hundred debug lines including a full dump of every GrowthBook gate with its resolved state (466 in my case), which is how I eliminated one candidate: app.asar contains a stealth restart scheduler (scheduleRestartWhenIdle, 600s idle timeout, cancels on window focus) that matches the symptom well, but its gate reads on=false for my account, so it is not the cause here.

Also ruled out since the original report

• Automatic Termination / TAL — the _kLSApplicationWouldBeTerminatedByTALKey=1 events occur after the quit begins, so they are a consequence of teardown, not the trigger.
• Third-party software — removing an antivirus suite entirely made no difference; quits continued for 55 minutes afterwards.
• Version mismatch between instances — only the first launch of the day ran an older build.

Suggested fix direction

Either make ScheduledTasks, LocalAgentModeSessionManager and the Cowork warm VM safe for N instances, or have a launching instance detect existing instances and skip re-initialising shared services rather than resetting them. Failing that, a clear statement that multiple instances are unsupported would at least let users stop at two deliberately.

Happy to provide the overnight monitor log or run any further diagnostic.