Problem
When running multiple Copilot CLI sessions in separate terminal windows (a common power-user workflow), idle sessions continue consuming significant memory — ~250-500MB each in RSS. With 5-10 sessions open, this easily consumes 2-5GB of RAM. Over days of accumulated use without restarting, this leads to macOS "Your system has run out of application memory" crashes.

Current state
Each idle copilot process holds its full working set in memory indefinitely:
PID: 46145, RSS: 510 MB (active session)
PID: 44441, RSS: 246 MB (idle)
PID: 48059, RSS: 243 MB (idle)
PID: 48926, RSS: 89 MB (idle)
Existing mitigation
--session-idle-timeout (added in 1.0.32) exits the session after a timeout, but this is a blunt instrument — users lose their interactive session context and terminal state. It also requires manually adding to every invocation since there is no settings.json key for it.
Proposed solution: Session hibernation
Similar to how VS Code suspends extension hosts and reduces memory for inactive windows, Copilot CLI should implement a hibernation mode for idle sessions:
Tier 1 — Lightweight idle reduction (low effort, high impact)
- After N minutes of no user input, proactively free caches (tree-sitter WASM, file caches, LSP connections, MCP server connections)
- Shut down idle subagent processes and shell sessions
- Release any in-memory indexes
- Goal: reduce idle RSS from ~250MB to ~50MB
Tier 2 — Full session hibernation (medium effort)
- Serialize minimal session state (conversation context, working directory, permissions) to disk
- Terminate the main Node.js process
- Show a "hibernated" indicator in the terminal (e.g., a static message)
- On any keypress, rapidly rehydrate from serialized state
- Goal: reduce idle memory to ~0MB while keeping the terminal window open
Tier 3 — Configuration improvements (low effort)
- Add
sessionIdleTimeout as a settings.json config key so users do not need a shell alias
- Add
sessionIdleAction config: "exit" (current behavior), "hibernate" (new), "reduce" (tier 1)
- Sensible defaults: consider enabling a default idle timeout or idle reduction
Prior art
- VS Code: Suspends extension hosts for inactive windows, disposes unused webviews
- tmux/screen: Detach/reattach pattern preserves session with zero memory for the client
- Jupyter: Kernel shutdown after idle timeout, with session resumption
Context
This is a growing problem as Copilot CLI adoption increases and power users naturally accumulate multiple sessions across different projects. On machines with 16GB RAM, just 6-8 idle sessions can consume 25%+ of total memory.
Problem
When running multiple Copilot CLI sessions in separate terminal windows (a common power-user workflow), idle sessions continue consuming significant memory — ~250-500MB each in RSS. With 5-10 sessions open, this easily consumes 2-5GB of RAM. Over days of accumulated use without restarting, this leads to macOS "Your system has run out of application memory" crashes.
Current state
Each idle copilot process holds its full working set in memory indefinitely:
Existing mitigation
--session-idle-timeout(added in 1.0.32) exits the session after a timeout, but this is a blunt instrument — users lose their interactive session context and terminal state. It also requires manually adding to every invocation since there is nosettings.jsonkey for it.Proposed solution: Session hibernation
Similar to how VS Code suspends extension hosts and reduces memory for inactive windows, Copilot CLI should implement a hibernation mode for idle sessions:
Tier 1 — Lightweight idle reduction (low effort, high impact)
Tier 2 — Full session hibernation (medium effort)
Tier 3 — Configuration improvements (low effort)
sessionIdleTimeoutas asettings.jsonconfig key so users do not need a shell aliassessionIdleActionconfig:"exit"(current behavior),"hibernate"(new),"reduce"(tier 1)Prior art
Context
This is a growing problem as Copilot CLI adoption increases and power users naturally accumulate multiple sessions across different projects. On machines with 16GB RAM, just 6-8 idle sessions can consume 25%+ of total memory.