Headless sidecar exits but parent shell process remains running indefinitely

[ellisjr]

Description

When running sidecar start --no-ui from a parent process (e.g., Claude Code's Bash tool), the sidecar CLI process completes (summary output emitted, session marked complete or error in sidecar list) but the parent shell process never terminates.

Steps to Reproduce

1. Launch sidecar headless from a background shell:

   sidecar start --model gemini --agent Plan --no-ui --timeout 20 --prompt "Review this file: some-file.md"

2. Wait for the sidecar session to complete (visible in sidecar list --status complete)
3. Check the parent shell process — it's still running

Expected Behavior

Parent shell process exits when sidecar CLI returns.

Actual Behavior

Parent shell process stays alive indefinitely. In our test, 10 out of 10 background sidecar launches became zombies, requiring manual kill/TaskStop.

Impact

When launching multiple sidecars in parallel (the documented multi-LLM pattern), zombie processes accumulate and confuse the user into thinking tasks are still running.

Environment

• macOS Darwin 23.5.0
• sidecar installed via npm install -g claude-sidecar
• Launched from Claude Code background bash tasks

[ellisjr]

Additional Impact: Breaks async notification workflow

The zombie process bug has a cascading effect beyond just confusing process lists. When sidecar is launched from a parent tool that relies on process exit to trigger completion notifications (e.g., Claude Code's run_in_background: true), the notification never fires because the parent bash process never exits.

Flow:

1. sidecar start --no-ui launched with run_in_background: true
2. Sidecar completes, emits summary to stdout, session marked complete in sidecar list
3. Parent bash process stays alive (zombie)
4. Task system sees status: running → never transitions to completed
5. Notification never sent → user must manually poll with "how's it going?"

This breaks the core documented async workflow pattern where the user is told "I'll notify you when it completes." Makes this bug higher severity than just a cosmetic process list issue — it defeats the purpose of background execution.