[BUG] Regression in 2.1.183 (VS Code extension, Remote-WSL): long-running child processes spawned by the Bash tool are killed/reaped — works in 2.1.181

Preflight Checklist

• [x] I have searched existing issues 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?

Summary

Starting with the 2.1.183 VS Code extension, any long-running process that the agent launches through the Bash tool is terminated shortly after launch. Browser processes (Chromium/Chrome) die immediately with exit code 144 (128 + signal 16, SIGSTKFLT), and ordinary single-process servers (e.g. Odoo, python3 -m http.server) start fine and respond, but are reaped between turns, so they are no longer available on the next tool call.

Downgrading the extension to 2.1.181 fully restores the previous behavior (long-running processes persist across turns as expected). The regression therefore landed in 2.1.182 or 2.1.183.

This breaks any workflow that relies on a persistent background process driven across multiple tool calls — in our case a visible Chromium driven over CDP for visual QA, and a local Odoo dev server.

Environment

• Extension: anthropic.claude-code
• Broken: 2.1.183 (installed 2026-06-19)
• Last known good: 2.1.181 (confirmed working after downgrade)
• Mode: VS Code Remote-WSL (Linux x64 server)
• OS: Ubuntu 22.04.5 LTS on WSL2, kernel 6.6.87.2-microsoft-standard-WSL2
• Node: v22.22.2
• VS Code server build: fcf604774b9f2674b473065736ee75077e256353
• Note: a separate npm-installed CLI (@anthropic-ai/claude-code 2.1.114) is also present and is not affected — only the in-VS-Code extension session shows the regression.

Actual behavior

• Multi-process trees (Chromium) are killed at startup → exit 144 (SIGSTKFLT/signal 16), empty captured output.
• Single-process servers survive within the launching turn but are reaped before the next turn.
• Foreground invocations of the same browser binary run normally (e.g. timeout 8 chromium ... about:blank exits 124 after producing healthy logs), confirming the binary itself works under the extension — only persistence is broken.

Additional notes / evidence

• chromium --version and chromium --headless --dump-dom (quick-exit) succeed with exit 0; only persistent launches fail.
• It is not a display/WSLg issue: headless launches fail the same way, and the same commands work in a plain terminal.
• It is not the OS sandbox in general: dangerouslyDisableSandbox-equivalent runs fail identically.
• The signal (16 / SIGSTKFLT) and the "reaped between turns" pattern suggest the regression is in the extension's child-process group / cleanup (reaping) logic, which now tears down detached/background children that previous versions left running.

Impact

Blocks any agent workflow that needs a persistent background process across turns (visual/browser QA over CDP, local dev servers such as Odoo, watchers, etc.).

Workaround

Either downgrade the extension to 2.1.181, or have the user launch the long-lived processes in their own terminal (outside the extension) and have the agent connect to them (CDP for the browser, HTTP/RPC for the server).

What Should Happen?

Expected behavior

A process launched with run_in_background: true (or detached) persists across subsequent tool calls/turns until it exits on its own or is explicitly stopped — as it did in 2.1.181 and earlier.

Error Messages/Logs

## Additional notes / evidence

- `chromium --version` and `chromium --headless --dump-dom` (quick-exit) succeed with exit 0; only persistent launches fail.
- It is not a display/WSLg issue: headless launches fail the same way, and the same commands work in a plain terminal.
- It is not the OS sandbox in general: `dangerouslyDisableSandbox`-equivalent runs fail identically.
- The signal (16 / `SIGSTKFLT`) and the "reaped between turns" pattern suggest the regression is in the extension's **child-process group / cleanup (reaping) logic**, which now tears down detached/background children that previous versions left running.

Steps to Reproduce

Steps to reproduce

In a VS Code Remote-WSL session running the 2.1.183 extension, have the agent run, via the Bash tool:

1. Browser case (dies immediately):

``bash
/path/to/chromium --headless=new --no-sandbox --disable-gpu \
--remote-debugging-port=9222 --user-data-dir=/tmp/prof about:blank
``

• As run_in_background: true, or backgrounded with & within a command → the task fails with exit code 144 and an empty output/log; no process survives.
• The exact same command launched in a plain user terminal (outside the extension) runs fine and opens a window.

1. Plain server case (reaped across turns):

``bash
python3 -m http.server 8099 --bind 127.0.0.1 # run_in_background: true
``

• Immediately after launch it responds HTTP 200 and the PID is alive.
• One or more turns later, the process is gone (server returns connection-refused, PID no longer exists), without any explicit stop from the agent.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.181

Claude Code Version

2.1.183

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_