REPL mode consumes 90-140% CPU when idle — no idle timeout or sleep mechanism

[jojoprison]

Description

The Heroku MCP server's --repl mode spawns npm exec heroku@latest --repl processes that consume 90-140% CPU per process even when completely idle (no MCP tools are being invoked).

Environment

• Heroku CLI: 11.0.0 (Homebrew, macOS ARM64)
• @heroku/mcp-server: v1.2.0 (bundled with CLI at /opt/homebrew/Cellar/heroku/10.17.0/)
• Node: v24.13.1
• OS: macOS 25.3.0 (Apple Silicon M-series)
• Client: Claude Code v2.1.73

Steps to Reproduce

1. Start an MCP client that connects to heroku mcp:start
2. Do not send any commands to the Heroku MCP server
3. Monitor CPU: `ps -eo pid,pcpu,rss,command | grep heroku`
4. Observe ~100% CPU usage from the REPL process

Observed Behavior

PID     CPU     RSS       COMMAND
62794   31%     206 MB    npm exec heroku@latest --repl
62810   146%    204 MB    npm exec heroku@latest --repl
62802   94%     208 MB    npm exec heroku@latest --repl

The --repl process appears to spin the Node.js event loop continuously rather than parking/sleeping when no input is available.

Over multiple MCP client sessions (Claude Code), these accumulate because the client doesn't always cleanly terminate child processes. With 3 stale sessions, we measured 450%+ CPU and 690 MB RAM from Heroku REPL processes alone.

Expected Behavior

1. Idle REPL should consume near-zero CPU (event loop should park when no stdin input)
2. Ideally: configurable idle timeout (HEROKU_MCP_IDLE_TIMEOUT_SECONDS) that auto-exits the REPL after inactivity
3. Consider: alternative to persistent REPL for MCP use case (e.g., on-demand CLI invocation with caching)

Impact

This is the #1 resource complaint for Heroku MCP users in the Claude Code ecosystem. The REPL design choice (per docs: "persistent CLI process for faster command execution") trades performance for continuous 100% CPU — even when the MCP server is never used in a session.

Combined with Claude Code's MCP lifecycle issues (anthropics/claude-code#1935), this causes laptops to overheat and batteries to drain from zombie REPL processes.

Suggested Fixes

1. REPL idle parking: Use process.stdin.pause() / event-driven wakeup instead of active polling
2. Idle timeout: Auto-exit REPL after N seconds of no input (configurable via env var)
3. Lazy REPL: Start REPL only on first tool invocation, not at MCP server startup
4. Graceful shutdown: Handle SIGTERM/SIGHUP from parent process to clean exit

Related

• anthropics/claude-code#36730 — Our detailed diagnostics from Claude Code side
• anthropics/claude-code#1935 — MCP servers not terminated on session exit

[JimmyCouch]

Chiming in, I could be wrong on this, but i was trying most of the day to get this working and noticed multiple hanging processes.

So i let claude run wild. Came up with this:

Root Issue

  Repository: heroku/heroku-mcp-server
  File: src/repl/heroku-cli-repl.ts

  The getHerokuCliCommandAndArgs() method spawns the Heroku CLI with --repl as a flag:

  // npx path
  return { cliCommand: 'npx', cliArgs: ['-y', 'heroku@latest', '--repl'] }

  // direct heroku path
  return { cliCommand: 'heroku', cliArgs: ['--repl'] }

  However, --repl is not a valid flag in the current Heroku CLI (heroku/11.0.0). The interactive REPL is exposed as a subcommand (heroku
  repl), not a flag (heroku --repl).

  When the REPL process starts and receives the invalid flag, the CLI exits with:
  Warning: --repl is not a heroku command.
  Error: Run heroku help for a list of available commands.

  The HerokuREPL class detects this warning and emits a fatalError. However, if fatalError fires during the restart loop, the command queue
  is never resolved — causing all MCP tool calls to hang indefinitely with no timeout or error surfaced to the client.

 Why multiple processes spawn

  The --repl bug causes a restart loop inside HerokuREPL. When the CLI exits with --repl is not a heroku command, the close event fires with
  a non-zero exit code, which triggers initializeProcess() again — immediately spawning a new failed process. This repeats indefinitely.

  Each attempt also goes through npm exec heroku@latest, so the full process tree per attempt is:

  heroku mcp:start
    └── heroku-mcp-server.mjs
          └── npm exec heroku@latest --repl    ← spawned per restart
                └── node .../heroku --repl     ← exits immediately with error

  Since the previous processes aren't cleaned up before restarting, each Claude Code session restart accumulates another tree of orphaned
  processes. On a machine that's been troubleshooting this issue for a while (many /mcp reconnect attempts), you can end up with dozens of
  zombie npm exec heroku@latest --repl processes consuming memory.

[Enase]

I confirm the same issue with similar env