claude-code - 💡(How to fix) Fix Feature request: configurable memory cap for Windows sandbox VM (CoworkVMService)

Problem

On Windows, Claude Code's sandbox runs Bash / Grep / Read tool calls inside a managed Hyper-V utility VM via CoworkVMService (display name "Claude"). On the host this surfaces as the vmmem process.

During a long, normal coding session (file reads, gh pr view calls, git log, etc.), vmmem grows steadily — observed ~2.6 GB working set / ~4.0 GB private memory after a few hours of moderate use. The VM only releases memory when the entire Claude Code session ends.

Current state (per docs)

• settings.json sandbox only exposes enabled, autoAllowBashIfSandboxed, excludedCommands, filesystem, network — no memory knob.
• No documented environment variable (e.g. CLAUDE_SANDBOX_MEMORY) controls VM memory.
• %UserProfile%\.wslconfig does not apply — the Cowork sandbox is separate from WSL2.
• No documented way to recycle / reset the sandbox mid-session.

Requested

One or more of:

1. A settings.json field, e.g. sandbox.maxMemoryMb, that caps the Hyper-V utility VM's RAM ceiling at session start (analogous to [wsl2] memory= in .wslconfig).
2. An environment variable equivalent for users who'd rather configure outside settings.
3. A slash command or tool to recycle the sandbox VM mid-session without restarting Claude Code.

Why this matters

For users on memory-constrained Windows machines (16 GB total is common) running Claude Code alongside Chrome, IDEs, simulators, EAS builds, etc., a multi-GB sandbox VM with no ceiling is a meaningful and unpredictable resource cost. Today the only mitigation is "end the session and start a new one," which loses context and is disruptive in the middle of a workflow.

Environment

• OS: Windows 10 Home 10.0.19045
• Claude Code: latest (CLI)
• Sandbox observed via Get-Service CoworkVMService and Get-Process vmmem