Problem

bash parses A && B & with && tighter than &, so it forks a subshell for the compound and backgrounds the subshell. Inside the subshell, B runs foreground, so the subshell waits for B to finish. When B is a process that never exits on its own (python3 -m http.server, yes > /dev/null, any daemon), the subshell is stuck in wait4 forever and leaks as an orphan reparented to init.

Observed in production

Across a small fleet over ~3 days:

• 8 unique stuck-terminal events (Agent idle for 1803s … tool=terminal) on 4 of 5 VMs
• 7 currently-leaked bash + server pairs across the fleet, oldest from 2026-04-14
• One agent appeared hung to the user for 30 minutes because the subshell's open stdout pipe kept the terminal tool's drain thread blocked (the subshell never closed FD 1)

Kernel stack of a live leak on each affected VM:

[<0>] do_wait+0x61/0xe0
[<0>] kernel_wait4+0xae/0x150
[<0>] __do_sys_wait4+0x9e/0xb0

Consistent fingerprint across leaks: PID ≠ PGID (bash is not session leader because the leaked one is a subshell, not the Popen child), PPID = 1 (outer bash exited, subshell reparented), same process group as the original setsid'd outer bash.

The common agent pattern that tripped it: cd X && python3 -m http.server 8000 &>/dev/null & sleep 1 && curl … — an agent's "start a local server then verify it" one-liner.

Relation to 933fbd8

Distinct from the set +m fix in 933fbd8, which addressed an interactive shell's job-control waiting at exit. set +m doesn't help here because bash -c is non-interactive and job control is already off — the problem is the subshell's own internal wait for its foreground B, not the outer shell's job tracking.

Fix

Walk the command shell-aware (respecting quotes, parens, brace groups, &>/>& redirects), find A && B & / A || B & at depth 0, and rewrite the tail to A && { B & }:

• Brace groups don't fork a subshell — they run in the current shell
• B & inside the group is a simple background (no subshell wait)
• The outer & is absorbed into the group, so the compound no longer needs an explicit subshell
• && error-propagation is preserved exactly: if A fails, && short-circuits and B never runs

Called once from BaseEnvironment.execute right after _prepare_command, so it runs for every backend (local, ssh, docker, modal, …) with no per-backend plumbing.

Examples

Edge cases handled

• Quoted strings (single/double) preserved via shared _read_shell_token
• Parenthesised subshells (...) skipped (separate bug class)
• Brace groups { ... } tracked for depth, making the rewrite idempotent
• &>/dev/null not mistaken for background &
• 2>&1, >&2, <&3 fd-redirects recognised by looking back for < / >
• ;, |, newlines reset chain state so the rewrite doesn't cross statements
• Comment lines (# …) left alone
• Backslash-escaped \&\& treated as literals

Tests

34 new tests in tests/tools/test_terminal_compound_background.py:

• TestRewrites — positive cases (10): A && B &, A \|\| B &, chained, mixed, multiline, realistic vela-shape
• TestPreserved — negative cases (7): simple bg, no compound, empty, whitespace-only
• TestRedirectsNotConfused — 5 redirect scenarios
• TestQuotingAndParens — 6 quoting / paren / comment / cmd-substitution / backslash cases
• TestIdempotence — 2 idempotency checks
• TestEdgeCases — 4 malformed / leading-whitespace / tab-separated

All 34 pass. Adjacent terminal-tool tests (114 more across test_terminal_tool.py, test_terminal_exit_semantics.py, test_terminal_requirements.py, etc.) still pass unchanged.

End-to-end validation

Provisioned a fresh test VM. Ran the exact vela-incident command through the real LocalEnvironment.execute path:

• Before: bash stuck in wait4 for 1800 s, server alive as its child, gateway inactivity timeout eventually fired
• After: execute() returns in 1.31 s with rc=0, curl sees 200, no leaked bash, only the intentional backgrounded server (orphaned to init, which is the agent's expressed intent)

Scope left for follow-up

• (A && B) & and other paren-subshell backgrounding has the same bug class but isn't the common agent pattern; adding paren coverage would require a different rewrite shape (the subshell is explicit) and is safer as a separate PR.
• The /stop-doesn't-reach-worker and SIGTERM-orphans-subprocess issues from fix(interrupt): propagate to concurrent-tool workers + opt-in debug trace #11907 are the upstream side of the same family of incidents — this PR complements that one by removing the most common trigger pattern entirely.

🤖 Generated with Claude Code