codex - 💡(How to fix) Fix macOS app + CLI: `js_repl = true` in config, but no `js_repl` tool in session [1 comments, 2 participants]

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.