# Reload Window does not terminate extension child processes (Claude Code hangs) **URL:** \ **Category:** Bug Reports\ **Tags:** macos, extensions\ **Created:** [April 26, 2026, 3:22pm UTC](https://forum.cursor.com/t/reload-window-does-not-terminate-extension-child-processes-claude-code-hangs/159070 "2026-04-26T15:22:27Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![bleung337](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/bleung337/32/106793_2.png) [@bleung337](https://forum.cursor.com/u/bleung337)\ **Post date:** [April 26, 2026, 3:22pm UTC](https://forum.cursor.com/t/reload-window-does-not-terminate-extension-child-processes-claude-code-hangs/159070/1 "2026-04-26T15:22:27Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug **Cursor version:** 3.1.17 (darwin-arm64) **OS:** macOS 14.8.5 (Darwin 23.6.0) **Extension:** anthropic.claude-code 2.1.120 ## Steps to reproduce 1. Install the Claude Code extension; open its panel and start a conversation. 2. Cmd+Shift+P, run “Developer: Reload Window”. 3. Observe that the Claude Code panel reloads blank, no input field. 4. In a terminal, run: ps aux | grep “native-binary/claude” | grep -v grep ## Expected On Reload Window, Cursor’s extension host should terminate child processes spawned by extensions, or at minimum expose an API so extensions can register children for cleanup. The new extension host instance should start with a clean IPC state. ## Actual The child `claude` process from the prior extension host survives reload. Observed up to 3 orphaned `claude` processes accumulating across reloads, around 3.3 GB resident memory combined. The new extension instance cannot bind IPC cleanly and hangs indefinitely with no input field. ## Workaround Run `pkill -f "native-binary/claude"` in a terminal, then reopen the panel and type `/resume` to restore the session. ## Regression note This did not occur on the prior Cursor version. It started after updating to 3.1.17. ## Related Filed with Anthropic: [Reload Window leaves orphaned claude child processes; panel hangs binding IPC · Issue #53554 · anthropics/claude-code · GitHub](https://github.com/anthropics/claude-code/issues/53554). They may need to clean up child processes in `deactivate()`, but the extension host not killing children on reload is also a contributor. ### Steps to Reproduce **Cursor version:** 3.1.17 (darwin-arm64) **OS:** macOS 14.8.5 (Darwin 23.6.0) **Extension:** anthropic.claude-code 2.1.120 ## Steps to reproduce 1. Install the Claude Code extension; open its panel and start a conversation. 2. Cmd+Shift+P, run “Developer: Reload Window”. 3. Observe that the Claude Code panel reloads blank, no input field. 4. In a terminal, run: ps aux | grep “native-binary/claude” | grep -v grep ## Expected On Reload Window, Cursor’s extension host should terminate child processes spawned by extensions, or at minimum expose an API so extensions can register children for cleanup. The new extension host instance should start with a clean IPC state. ## Actual The child `claude` process from the prior extension host survives reload. Observed up to 3 orphaned `claude` processes accumulating across reloads, around 3.3 GB resident memory combined. The new extension instance cannot bind IPC cleanly and hangs indefinitely with no input field. ## Workaround Run `pkill -f "native-binary/claude"` in a terminal, then reopen the panel and type `/resume` to restore the session. ## Regression note This did not occur on the prior Cursor version. It started after updating to 3.1.17. ## Related Filed with Anthropic. They may need to clean up child processes in `deactivate()`, but the extension host not killing children on reload is also a contributor. ### Expected Behavior **Cursor version:** 3.1.17 (darwin-arm64) **OS:** macOS 14.8.5 (Darwin 23.6.0) **Extension:** anthropic.claude-code 2.1.120 ## Steps to reproduce 1. Install the Claude Code extension; open its panel and start a conversation. 2. Cmd+Shift+P, run “Developer: Reload Window”. 3. Observe that the Claude Code panel reloads blank, no input field. 4. In a terminal, run: ps aux | grep “native-binary/claude” | grep -v grep ## Expected On Reload Window, Cursor’s extension host should terminate child processes spawned by extensions, or at minimum expose an API so extensions can register children for cleanup. The new extension host instance should start with a clean IPC state. ## Actual The child `claude` process from the prior extension host survives reload. Observed up to 3 orphaned `claude` processes accumulating across reloads, around 3.3 GB resident memory combined. The new extension instance cannot bind IPC cleanly and hangs indefinitely with no input field. ## Workaround Run `pkill -f "native-binary/claude"` in a terminal, then reopen the panel and type `/resume` to restore the session. ## Regression note This did not occur on the prior Cursor version. It started after updating to 3.1.17. ## Related Filed with Anthropic. They may need to clean up child processes in `deactivate()`, but the extension host not killing children on reload is also a contributor. ### Operating System MacOS ### Version Information **Cursor version:** 3.1.17 (darwin-arm64) **OS:** macOS 14.8.5 (Darwin 23.6.0) **Extension:** anthropic.claude-code 2.1.120 ## Steps to reproduce 1. Install the Claude Code extension; open its panel and start a conversation. 2. Cmd+Shift+P, run “Developer: Reload Window”. 3. Observe that the Claude Code panel reloads blank, no input field. 4. In a terminal, run: ps aux | grep “native-binary/claude” | grep -v grep ## Expected On Reload Window, Cursor’s extension host should terminate child processes spawned by extensions, or at minimum expose an API so extensions can register children for cleanup. The new extension host instance should start with a clean IPC state. ## Actual The child `claude` process from the prior extension host survives reload. Observed up to 3 orphaned `claude` processes accumulating across reloads, around 3.3 GB resident memory combined. The new extension instance cannot bind IPC cleanly and hangs indefinitely with no input field. ## Workaround Run `pkill -f "native-binary/claude"` in a terminal, then reopen the panel and type `/resume` to restore the session. ## Regression note This did not occur on the prior Cursor version. It started after updating to 3.1.17. ## Related Filed with Anthropic: [Reload Window leaves orphaned claude child processes; panel hangs binding IPC · Issue #53554 · anthropics/claude-code · GitHub](https://github.com/anthropics/claude-code/issues/53554). They may need to clean up child processes in `deactivate()`, but the extension host not killing children on reload is also a contributor. ### Does this stop you from using Cursor Sometimes - I can sometimes use Cursor ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [April 27, 2026, 10:13am UTC](https://forum.cursor.com/t/reload-window-does-not-terminate-extension-child-processes-claude-code-hangs/159070/5 "2026-04-27T10:13:49Z")
Hey @bleung337! Looks similar to the issue reported here. > [@Closing/Killing Cursor IDE does not kill all background processes](https://forum.cursor.com/t/closing-killing-cursor-ide-does-not-kill-all-background-processes/159063/5): > > Hey, thanks for the report. This is a known issue. The extension host and related processes sometimes ignore SIGTERM when you close the window, so the tray icon and background processes stay alive and you have to kill them manually. It’s not only on Linux, there are similar reports on macOS and Windows too: [Xtension-host processes orphaned after window close/reuse — SIGTERM ignored, requires SIGKILL](https://forum.cursor.com/t/xtension-host-processes-orphaned-after-window-close-reuse-sigterm-ignored-requires-sigkill/155821)[Windows 11 CPU runs hot even after shutting down Cursor](https://forum.cursor.com/t/windows-11-cpu-runs-hot-even-after-shutting-down-cursor/156643) We’ve logged the bug, but I can’t shar… I’ve added your (excellent) detailed report to the ticket that Dean logged. Could you please also confirm that you see the same behavior on _v3.2_?