Desktop app rewrites removed feature flag js_repl into config.toml on every startup

[liby]

Summary

The Codex desktop app writes features.js_repl = false back into config.toml on every launch, even when the user has manually removed the line. js_repl is reported as a removed-stage feature flag by codex features list.

Environment

• codex-cli 0.133.0
• Codex desktop app 26.519.41501
• macOS (Darwin 25.4.0, arm64)

Steps to reproduce

1. Quit the Codex desktop app completely.
2. Edit $CODEX_HOME/config.toml and remove the features.js_repl = false line.
3. Confirm with grep js_repl $CODEX_HOME/config.toml that the line is gone.
4. Run codex features list and codex doctor. The line stays absent; the CLI does not write it back.
5. Launch the Codex desktop app.
6. Re-check config.toml. features.js_repl = false is present again.

Observed behavior

After every desktop-app launch, features.js_repl = false is restored.

Code reference

In the desktop bundle at Codex.app/Contents/Resources/app.asar, file .vite/build/main-*.js:

var Qn = [`features.js_repl`, /* ... */];

async function $n({ appServerConnection, desktopFeatureAvailability, ... }) {
  let d = await St({ ... });
  await appServerConnection.sendAppServerRequest(`config/batchWrite`, {
    edits: er(d), // Qn.map(t => ({ keyPath: t, mergeStrategy: `replace`, value: d?.[t] ?? null }))
    expectedVersion: null,
    filePath: null,
    reloadUserConfig: true,
  });
}

$n is awaited during app startup. The features.js_repl keyPath is written with mergeStrategy: "replace" unconditionally.

CLI feature stage

$ codex features list | grep js_repl
js_repl              removed   false
js_repl_tools_only   removed   false

Impact

A user who deletes features.js_repl = false finds it restored on the next desktop-app launch, with no UI control to suppress the rewrite. This is confusing because the CLI reports the flag as removed.

[liby]

Update: Confirmed that the [mcp_servers.node_repl] block is also restored on every desktop-app launch via the same config/batchWrite call. The second entry in the hardcoded keyPath list (mcp_servers.${e.wn}) resolves to mcp_servers.node_repl.

So the desktop app unconditionally rewrites two keys on startup:

1. features.js_repl (set to false)
2. mcp_servers.node_repl (full MCP server config block)

Both reappear after manual deletion following the same reproduction steps described above.

[yui-stingray]

Confirmed on the Rust side: js_repl and js_repl_tools_only are removed feature keys, and config loading intentionally ignores them when present under [features]. config/batchWrite can still persist arbitrary config edits to config.toml, so the Desktop bundle snippet in this issue points to startup sync as the likely source of features.js_repl = false being restored. A fix should probably filter removed feature keys before issuing or persisting those startup config writes. The same pattern may also explain the reported mcp_servers.node_repl restoration, but I only see that path from the bundle snippet here rather than checked-in Desktop source.