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.playwrightconfigured
Steps to reproduce
- Enable
js_repl = truein~/.codex/config.toml. - Start a fresh Codex desktop app session on macOS, or a fresh Codex CLI session.
- Try to use a workflow that depends on
js_repl(for exampleplaywright-interactive). - Check the actually available tools/capabilities in the session.
Expected behavior
One of these should happen consistently:
js_replis 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_repltool. - 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_replas 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.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Small update from another macOS setup: on
codex-cli 0.128.0,js_replnow appears to be explicitly removed: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/skillsplaywright-interactivestill instructs users/agents to enablejs_repland usejs_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 tonode_repl.@jonasjancarik, we never shipped
js_repl. It was marked as under development which means it was not intended for external use.@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
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?
Same happens to me. Codex auto changes the value to False everytime.