openai / openai/codex

Codex-injected Node REPL starts for every unused subagent and is not reaped

Open
#42,005 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

app bug config mcp performance subagent windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.51511

What subscription do you have?

Pro 20x

What platform is your computer?

No response

What issue are you seeing?

Codex Desktop automatically injects and eagerly starts its bundled node_repl MCP for every task/subagent, even when neither JavaScript nor Browser tooling is used.

Environment:

  • Codex Desktop 26.825.6671.0
  • Native Windows x64
  • Bundled Browser plugin 26.825.51511
  • One multi-agent wave with 8 subagents

The user did not install node_repl. Codex writes it into the global configuration:

[mcp_servers.node_repl]
args = []
command = "/node_repl.exe"
startup_timeout_sec = 120

Its environment explicitly connects it to the Browser/Chrome runtime. None of the subagents invoked Node REPL, Browser, Chrome, visualization, or JavaScript tools.

The ordinary default, worker, and explorer subagent profiles explicitly contained:

[mcp_servers.node_repl]
command = "cmd.exe"
args = ["/d", "/c", "exit", "0"]
enabled = false

Despite that override, after the subagents completed, the current Desktop app-server retained:

  • 6 node_repl.exe processes
  • 19 additional Node processes belonging to injected MCP/app-tool stacks

Across all live Codex app-servers, process-tree inspection found:

  • 11 node_repl.exe processes
  • 39 node.exe processes

All 50 were verified descendants of Codex app-server processes. None belonged to active Node development work. Terminating those exact descendants reduced the Codex-owned Node/Node REPL count to zero without affecting the active Codex task.

What steps can reproduce the bug?

Just have a session with subagents

What is the expected behavior?
  1. Do not start node_repl until an agent first invokes its JavaScript or Browser functionality.
  2. Honor per-agent enabled=false before initializing inherited/global MCP servers.
  3. Do not attach node_repl to subagents that have no Browser, Chrome, visualization, or JavaScript tools.
  4. Terminate the node_repl kernel immediately when the owning subagent completes.
  5. Reuse a bounded pool if startup latency makes lazy creation undesirable.
Additional information

Actual behavior:

Codex starts another Node REPL for every subagent at session initialization and leaves completed-agent kernels running. Process count and memory usage therefore grow linearly with multi-agent work, even though the feature was never used.

There is no documented user-configurable idle TTL or lazy-start option. The only reliable workarounds are disabling a Codex-provided feature, restarting Desktop, or externally terminating processes by PID ancestry.

Related:

This report is specifically about native Windows, the current app build, unused subagents, and the failure to honor per-agent enabled=false for a Codex-injected MCP.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The report names no repository files, tests, or entry points. Start by reproducing a multi-agent session on native Windows and tracing initialization and cleanup for the injected node_repl MCP. Done means unused subagents do not start it, disabled per-agent configuration is honored, and completed-agent processes are reaped.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, rust
Domain
desktop, devtools, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.