[BUG] Desktop: computer-use side-panel dock fires phantom quit event; "Wait for Claude" silently quits app after task; no setting to disable docking (multi-monitor)

Environment

• Claude Desktop (Cowork) 1.11847.5
• macOS (Darwin 25.5.0), multi-monitor setup (main 1920x1080 landscape + 1080x1920 portrait secondary)

Summary

Every time a session launches the computer-use tool, the desktop app docks itself into the compact side panel and, ~4 seconds later, receives a quit event the user never initiated. The "Claude is still working" dialog appears, and its highlighted default button ("Wait for Claude") doesn't dismiss the quit — it defers it, so the app silently quits (active thread and all) the moment the tool use finishes.

Three related findings:

1. Phantom quit event fired by the cu-side-panel dock path (the core bug)

Reproducible log signature from ~/Library/Logs/Claude/main.log — dock → glow → quit attempt ~4s later, every time computer use starts:

17:31:02 [info] [cu-side-panel] docked
17:31:02 [info] [cu-glow] window created requested={"x":-1080,"y":-440,"width":1080,"height":1920} ...
17:31:04 [warn] [event-loop-stall] main process blocked for 698ms ...
17:31:06 [info] beforeQuit: handler fired, going down
17:31:06 [info] beforeQuit: vetoed by before-quit interceptor
17:31:24 [info] [Stop hook] Query completed for session local_...
17:31:24 [info] [cu-side-panel] restored

Same pattern again minutes later:

17:37:36 [info] [cu-side-panel] docked
17:37:36 [info] [cu-glow] shown bounds={"x":0,"y":0,"width":1920,"height":1080}
17:37:40 [info] beforeQuit: handler fired, going down
17:37:40 [info] beforeQuit: vetoed by before-quit interceptor

6 occurrences of vetoed by before-quit interceptor in the current log, all matching this pattern. No Cmd+Q or quit was issued by the user. The consistent ~4s delay after docking suggests something in the dock/glow window path is tripping Electron's quit handling (window-all-closed-style handler when the main window collapses?).

2. "Wait for Claude" arms a quit the user never requested

The dialog's options are "Quit anyway" / "Wait for Claude" (highlighted default) / "Cancel". "Wait for Claude" does not cancel the phantom quit — it queues it. The full onQuitCleanup → readyForQuit shutdown sequence then runs as soon as the session finishes, killing the app and the active thread. An accidental Enter or click on the default button of a dialog the user never caused results in the app quitting itself mid-workflow. "Cancel" is the only safe choice and it's the last option.

3. No setting to disable the dock-to-side-panel behavior

The dock-on-computer-use behavior appears hardcoded (only internal cuDockStateChanged / isDocked strings in the bundle; no preference key or feature flag). On multi-monitor setups this is pure loss: in the 17:31 occurrence above, the cu-glow overlay went up on the secondary display (x:-1080) — the agent was working on a different monitor entirely — yet the main window on the primary display still collapsed. Please consider a setting (or at minimum, skip docking when the controlled display doesn't contain the Claude window).

Expected

• Launching computer use never generates a quit event.
• The main window doesn't forcibly dock, or this is configurable — especially when computer use targets a different display.
• A quit-confirmation dialog's default action is never "quit later without asking again."

Actual

Window collapses on every computer-use launch, a quit dialog the user never triggered appears, and the default button schedules an unattended quit of the app and active session.