[macOS] Chrome and Computer Use tools missing only in project threads after Desktop 26.730.61639 update

Summary

After updating and fully restarting Codex Desktop on macOS on 2026-08-05, the bundled Chrome and Computer Use plugins remain installed and enabled, but their shared node_repl tool is not provisioned consistently into project-backed threads.

The same installation can use Chrome and Computer Use successfully in a projectless thread. In affected project threads, the plugin skills may be visible, but mcp__node_repl__js is either absent from the tool set or advertised but not callable.

This is a regression after the Desktop update, not a Chrome extension installation problem, a macOS app permission problem, or a user project deletion/recreation problem.

Related general report: #30026. This issue adds a current-build macOS reproduction and local root-cause evidence about Desktop's Browser Use configuration reconciliation.

Environment

• Platform: macOS 26.5.2
• Codex Desktop app bundle: com.openai.codex
• Codex Desktop version: 26.730.61639
• Desktop build: 6234
• Update/restart date: 2026-08-05
• Chrome extension version: 1.2.27236.6274_0
• Bundled plugins:
• chrome@openai-bundled = enabled
• computer-use@openai-bundled = enabled
• Bundled Computer Use plugin version: 1.0.1000621

Opaque affected thread IDs, included only for OpenAI-side correlation:

• 019fd04d-6a13-7922-a683-ecc67b356b57
• 019fd06e-a1e0-7bb3-8619-14874ffae9ad

Steps to reproduce

1. Update Codex Desktop to 26.730.61639 on macOS.
2. Fully restart the application.
3. Confirm the bundled Chrome and Computer Use plugins are enabled.
4. Open or create a task backed by an existing local project.
5. Mention Chrome or Computer Use and ask the task to inspect/use the corresponding app.
6. Observe that the skill is present but mcp__node_repl__js is missing or unavailable.
7. Create a projectless task in the same running Desktop installation.
8. Repeat the request and observe that Chrome/Computer Use works there.

Expected behavior

If the bundled plugins are enabled and their runtime is healthy, every eligible new task should receive the same callable node_repl capability regardless of whether the task is project-backed or projectless.

Actual behavior

Tool provisioning differs by task type/state:

same macOS user
same Codex Desktop process
same enabled Chrome and Computer Use plugins
same Chrome profile and extension
same node_repl binary and config

projectless task -> Chrome/Computer Use callable
project-backed task -> mcp__node_repl__js absent or unavailable

One affected task incorrectly concluded that macOS had denied access to a user folder and reported that application-control skills were unavailable. The same folder and applications were accessible from a projectless task, so the macOS-wide permission explanation does not fit the observed behavior.

What was verified locally

The following components are present and healthy:

• Chrome is running.
• The ChatGPT Chrome extension is installed and enabled in the active profile.
• The Native Messaging Host exists and its manifest resolves correctly.
• The bundled browser-client.mjs exists.
• Its SHA-256 matches a trusted value in the generated configuration.
• The bundled node_repl and Computer Use executables exist.
• Computer Use is correctly signed.
• The required @oai/sky module is installed.
• The mcp_servers.node_repl configuration points to the bundled executable.
• The same installation works from a projectless task.

Important finding: features.js_repl = false is generated by Desktop and is not the cause

The user config contains:

[features]
js_repl = false

[mcp_servers.node_repl]
command = "<APP_BUNDLE>/Contents/Resources/cua_node/bin/node_repl"
startup_timeout_sec = 120

Initially this looked causal, but further investigation disproved that hypothesis:

1. codex features list reports:

``text
js_repl removed false
``

1. Chrome and Computer Use work in a projectless task while this exact line remains present.

1. The installed Desktop application contains a BrowserUseThreadConfig path that explicitly defines:

``js
{"features.js_repl": false}
``

1. That same path builds a config/batchWrite request covering:

``text
features.js_repl
mcp_servers.node_repl
mcp_servers.computer-use
``

This appears to disable the removed/legacy built-in JS REPL while provisioning the current MCP-based node_repl. Removing the line manually is not a durable workaround because Desktop writes it back.

Configuration-write evidence

The config file was atomically recreated by Codex Desktop. Its birth time and modification time were both:

2026-08-05 08:53:51 +0300

At the matching UTC time, the Desktop log records reads, plugin reconciliation, and successful writes from the primary renderer:

2026-08-05T05:53:51.210Z ... method=config/read ... originWebcontentsId=1
2026-08-05T05:53:51.529Z ... method=plugin/list ... originWebcontentsId=1
2026-08-05T05:53:52.122Z ... method=config/batchWrite ... errorCode=null ... originWebcontentsId=1

The same refresh sequence also produced a version race shortly beforehand:

2026-08-05T05:53:29.747Z ... method=config/batchWrite ... errorCode=-32600
config_write_error_code=configVersionConflict
Configuration was modified since last read. Fetch latest version and retry.

There were multiple successful config/batchWrite calls around plugin/skills refresh. This may be relevant if task capability snapshots are constructed while Browser Use configuration is being reconciled.

Historical confirmation

On 2026-07-19, a Codex task removed features.js_repl = false from the config after explicit user approval. By the next day's new task creation, Codex Desktop had regenerated the config and restored the line. No later agent/session command that manually added the line was found.

This supports that the key is Desktop-managed compatibility configuration rather than a manual user choice.

Likely failing layer

The evidence points to task capability assembly/provisioning after the update:

plugins installed and enabled
  -> BrowserUseThreadConfig generates node_repl configuration
  -> node_repl runtime is valid
  -> task-specific tool set is assembled
  -> some project-backed tasks do not receive a callable mcp__node_repl__js

The current evidence does not show that features.js_repl = false disables the MCP server.

Suggested areas to inspect

1. Compare capability/tool-set assembly for project-backed and projectless tasks.
2. Verify that Browser Use thread config is applied before the task tool snapshot is finalized.
3. Check whether plugin/skills refresh and concurrent config/batchWrite calls can leave a task with a stale capability snapshot.
4. Retry or serialize Browser Use config writes after configVersionConflict.
5. Add a macOS release-gate test:

``text
update Desktop and restart
Chrome + Computer Use enabled
create project-backed task
create projectless task
both must receive callable mcp__node_repl__js
``

1. Stop persisting features.js_repl once all supported runtimes treat it as removed, or document that it intentionally disables only the legacy implementation.

Workaround

Creating a new projectless task currently restores Chrome and Computer Use access. Deleting the project, reinstalling the Chrome extension, changing macOS Files & Folders permissions, or manually removing features.js_repl = false should not be required.

Privacy

All usernames, project names, document names, local user paths, account data, and task contents have been omitted. Log excerpts contain only timestamps, method names, renderer identifiers, version information, and configuration error codes needed to diagnose the regression.