macOS app + CLI: `js_repl = true` in config, but no `js_repl` tool in session

Resolved 💬 6 comments Opened Apr 17, 2026 by hlemonnier Closed May 8, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On macOS, ~/.codex/config.toml had js_repl = true, but the active session did not expose any js_repl tool/capability.

The same problem was observed both in the Codex desktop app and in the Codex CLI.

That makes skills such as playwright-interactive unusable even though the feature appears enabled in config.

Environment

  • Platform: macOS
  • Codex App version: 26.415.21839 (1763)
  • Also reproduced in: Codex CLI

Config / context

[features]
js_repl = true

Also present in the same config:

  • sandbox_mode = "danger-full-access"
  • mcp_servers.playwright configured

Steps to reproduce

  1. Enable js_repl = true in ~/.codex/config.toml.
  2. Start a fresh Codex desktop app session on macOS, or a fresh Codex CLI session.
  3. Try to use a workflow that depends on js_repl (for example playwright-interactive).
  4. Check the actually available tools/capabilities in the session.

Expected behavior

One of these should happen consistently:

  • js_repl is actually available in the session after restart, or
  • Codex explicitly reports that the feature is enabled in config but not active in the current session, with a concrete remediation path.

Actual behavior

  • The config reports js_repl = true.
  • The running session still has no usable js_repl tool.
  • The same mismatch was observed in both the desktop app and the CLI.
  • The mismatch is only discoverable indirectly by inspecting config and then noticing the tool is absent.

Why this is a problem

  • It breaks skills that declare js_repl as a hard precondition.
  • It is confusing because the source of truth is split between config state and actual session capability state.
  • From inside the session, there is no first-class signal that says: "configured but not active in this session".
  • The issue is more severe because it is not isolated to one surface; it affects both the app and the CLI.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #18258
  • #16702
  • #16574

Powered by Codex Action

jonasjancarik · 2 months ago

Small update from another macOS setup: on codex-cli 0.128.0, js_repl now appears to be explicitly removed:

browser_use                         stable             true
js_repl                             removed            false
js_repl_tools_only                  removed            false

At the same time, current Codex sessions expose the newer Node REPL MCP surface (node_repl / mcp__node_repl__js) for JavaScript execution, and Browser Use already documents that path.

The confusing part is that official skills can still depend on the removed name. For example, openai/skills playwright-interactive still instructs users/agents to enable js_repl and use js_repl_reset, which is impossible on current Codex.

Related skills issue: https://github.com/openai/skills/issues/386

It would help if Codex either provided compatibility/alias guidance for old js_repl-based skills, or surfaced a clear diagnostic that the skill depends on a removed feature and should be migrated to node_repl.

etraut-openai contributor · 2 months ago

@jonasjancarik, we never shipped js_repl. It was marked as under development which means it was not intended for external use.

jonasjancarik · 2 months ago

@etraut-openai ok, interesting! Thanks for the quick response. What should happen with the playwright-interactive skill though? See https://github.com/openai/skills/issues/386#issuecomment-4409187421

thx

Alex1kenobi · 1 month ago

Same happens to me. Can't use this for QA sessions with the pluging in app browser.
I save js_repl, buth after save and open Codex, auto change into "False" and codex tell me I cannot use the browser.
Very frustrating. Any update about this?

LLuna-a · 29 days ago

Same happens to me. Codex auto changes the value to False everytime.