Reload Window does not terminate extension child processes (Claude Code hangs)

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. 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. 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

Hey @bleung337!

Looks similar to the issue reported here.

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?