[macOS][26.831.21537] cua_repl trusted worker drops NODE_REPL_TRUSTED_SERVICES and crashes before browser attachment

What version of the Codex App are you using?

26.831.21537, build 7579

What subscription do you have?

Business

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

The in-app Browser cannot attach to an open tab because the trusted JavaScript worker exits before browser discovery.

Every cua_repl call fails immediately with:

trusted Node process exited unexpectedly; kernel reset, rerun your request

The Desktop logs show the underlying exception:

SyntaxError: "undefined" is not valid JSON
    at JSON.parse (<anonymous>)
    at Object.<anonymous> (.../trusted-worker.js:19:33)

Line 19 is:

const configuredServices = JSON.parse(process.env.NODE_REPL_TRUSTED_SERVICES);

~/.codex/config.toml contains a valid NODE_REPL_TRUSTED_SERVICES JSON value, and codex mcp get node_repl --json reports that value in the effective transport configuration. The managed trusted worker still receives undefined.

This fails before any target URL, browser tab, or site authentication is involved. The in-app Browser can be visibly open and loaded while the control worker continues to crash.

What steps can reproduce the bug?

Open an in-app Browser tab in Codex Desktop.
Start a local Codex task and ask it to use the in-app Browser.
Run the documented first connection call, or the minimal state call:
```
await cua.getState();
```
The trusted process exits immediately.
Reset the JavaScript kernel and retry a trivial call with no browser access. The same process exit occurs.
Fully restart Codex Desktop and retry. The failure remains.

The Browser worked earlier on the same machine before updating to this build.

What is the expected behavior?

The trusted worker should inherit the configured trusted services, stay running, and attach to the open in-app Browser tab.

If the variable is genuinely missing, the launcher should return a clear configuration error instead of crashing on JSON.parse(undefined).

Additional information

This looks like an environment-propagation regression between the app-managed MCP configuration and the trusted worker process. It is not a target-site failure.

Related reports:

Those reports cover adjacent initialization, trusted-RPC, and generated-runtime failures. This report captures the narrower invariant: the effective config contains NODE_REPL_TRUSTED_SERVICES, but the managed trusted worker does not inherit it.

No local app bundle or sandbox workaround is installed.

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

Codex Chrome browser connection crashes during initialization #42485

Powered by Codex Action

Additional macOS desktop diagnostic evidence.

In-app feedback was submitted successfully:
01a06f54-9063-7dc3-a19d-62101866efe4

Desktop: ChatGPT.app, version 26.901.41123, build 7942
Bundle identifier: com.openai.codex
These version/build numbers identify the desktop, not the standalone CLI.

CONFIRMED — At 2026-09-05T01:37:45Z, worker stderr contained:

SyntaxError: "undefined" is not valid JSON
at JSON.parse ()
at Object. (.../trusted-worker.js:19:33)

Read-only static inspection identifies line 19 as:
const configuredServices = JSON.parse(process.env.NODE_REPL_TRUSTED_SERVICES);

SEPARATE FAILURE — At 2026-09-05T02:10:16Z, a Computer Use call to open Calculator returned:
"trusted Node process exited unexpectedly; kernel reset, rerun your request"

No matching underlying exception or exit code/signal was recovered for that later invocation.

UNVERIFIED — Whether the Calculator failure had the same cause, and why the earlier configuration input was invalid. I have not established that a valid configured value was dropped.

No configuration or bundled files were modified during diagnosis.

Is there a released desktop build addressing this failure, or a supported recovery procedure?

Follow-up with a subsequent Calculator reproduction.

Installed desktop: ChatGPT.app 26.901.41600, build 7982; bundle identifier com.openai.codex. The running desktop version/build was not independently verified.

One validated correction to shell_environment_policy.set.SKY_CUA_SERVICE_PATH, followed by a manual desktop restart, did not resolve the Calculator smoke test. This was configuration cleanup, not a confirmed crash fix.

Test start: 2026-09-05T14:18:10.493Z.

The single attempt returned:

trusted Node process exited unexpectedly; kernel reset, rerun your request

At 2026-09-05T14:18:24.583283Z, the same backend recorded this exception during the call:

SyntaxError: "undefined" is not valid JSON
    at JSON.parse (<anonymous>)
    at Object.<anonymous> (.../trusted-worker.js:19:33)

Static inspection identifies that line as parsing process.env.NODE_REPL_TRUSTED_SERVICES. Why the configuration input was invalid remains unknown. The original 2026-09-05T02:10:16Z Calculator failure remains unlinked.

Feedback was submitted for this reproduction. The confirmation displayed the SAME ID as before:
01a06f54-9063-7dc3-a19d-62101866efe4

Is there a released desktop fix, or a supported diagnostic for inspecting the configuration actually delivered to the app-managed trusted worker?

Additional evidence from a September 7 reproduction and subsequent read-only configuration inspection.

Test window: 2026-09-07T17:02:04Z–17:02:13Z. Exactly one mcp__cua_repl.js call was attempted:

let app = await cua.getApp("Calculator");

It failed during initialization with:

trusted Node process exited unexpectedly; kernel reset, rerun your request

At 2026-09-07T17:02:09.891554Z, the same backend recorded this exception between the call's invocation and completion:

SyntaxError: "undefined" is not valid JSON
    at JSON.parse (<anonymous>)
    at Object.<anonymous> (.../trusted-worker.js:19:33)

Dated environment metadata, inspected before this test: installed ChatGPT.app 26.901.51231, build 8109, identifier com.openai.codex; macOS 27.0, build 26A5425a. The running desktop version/build was not independently verified. Process counts and memory were not assessed. These observations do not establish a build-specific, OS, permissions, or memory-related cause.

Subsequent static inspection found:

The unified Computer Use 26.901.51231 .mcp.json definition for cua_repl contains NODE_REPL_TRUSTED_SERVICES; its stored value parses as a JSON object.
The separate user node_repl definition also contains the variable; its stored value parses as a JSON object. This does not establish inheritance by cua_repl.
The unified launcher's scripts/launch.mjs explicitly assigns the variable using JSON.stringify(...) in the environment passed when spawning its child.
The installed embedded worker's source-relative line 19 parses process.env.NODE_REPL_TRUSTED_SERVICES.

These static findings do not establish which launcher/source the failed worker used or what environment it received. JSON validity and top-level type do not establish full schema validity. Neither a specific stored-configuration defect nor a particular runtime handoff failure has been demonstrated.

Can maintainers provide a supported diagnostic that identifies the actual worker/launcher and records this variable's presence, JSON parse status, and top-level type at worker startup without exposing its raw value?

In-app feedback

Feedback submitted for the September 7 reproduction.
Feedback ID: 01a06f54-9063-7dc3-a19d-62101866efe4

Additional diagnostic evidence for desktop 26.901.51231 (build 8109), macOS 26.6.2 (25G83), bundled Node v24.19.0 and bundled Codex CLI 0.153.4.

A freshly opened desktop Work chat reports the same trusted Node process exit when using the in-app Browser. The underlying stderr for that actual Work invocation has not been recovered.

Separately, launching the installed unified runtime from its declared MCP configuration in a short-lived diagnostic process and calling await cua.getState(); produces:

SyntaxError: "undefined" is not valid JSON
    at JSON.parse (<anonymous>)
    at Object.<anonymous> (.../trusted-worker.js:19:33)

Important limitation: this standalone probe uses the environment declared in the installed .mcp.json plus a minimal PATH. It does not inherit the regular shell environment or reproduce all desktop invocation metadata. It therefore demonstrates the error signature, not that the desktop failure has the same cause. Browser-only initialization and a separate legacy-runtime control fail with the same signature in this diagnostic environment. Bare imports of the installed browser service and CUA module succeed.

The machine has a customized Codex configuration; this is not a verified clean-profile reproduction. No settings, app bundle, plugin cache files, or permissions were changed during these diagnostics. No account data, session transcripts, or raw configuration are attached.

Is there a supported diagnostic for observing the trusted worker's launcher identity and the presence/parse status of NODE_REPL_TRUSTED_SERVICES without exposing its value? Is a released fix or supported recovery procedure available for this build?

September 11 follow-up: basic REPL recovered; native Computer Use remains blocked

Follow-up to my September 5 and 7 comments. Further diagnostics found a smaller failing case and a partial local recovery, but native Mac Computer Use is still not working. This is not a confirmed root cause or a general recovery procedure.

Environment

Desktop About: 26.903.71938. Installed application bundle: build 8576, identifier com.openai.codex. Hardware: M2 Max MacBook Pro, 32 GB RAM; macOS 27.0. The exact current macOS build remains unverified.

Installed components: unified-computer-use 26.903.71938, computer-use 1.0.1000968, @oai/sky 0.6.26, @oai/cua 0.2.4, bundled Node 24.20.0. These are installed metadata, not verification of the package bytes loaded by every failed worker.

Minimal failing case before the configuration experiment

On 2026-09-11, 19:05:18–19:05:21 UTC, one mcp__node_repl__js call contained only:

nodeRepl.write("MAC_NODE_REPL_STAGE_1 " + new Date().toISOString());

No marker was returned. The result was:

trusted Node process exited unexpectedly; kernel reset, rerun your request

A bounded log query recovered this exception at 19:05:21.855776 UTC:

SyntaxError: "undefined" is not valid JSON
    at JSON.parse (<anonymous>)
    at Object.<anonymous> (.../trusted-worker.js:19:33)

The invocation and exception records share a backend identifier. Stderr lacks a task/call identifier, so this is time/backend correlation, not definitive worker-to-call linkage. No Computer Use package import or native-app operation was present in the submitted code.

Partial recovery and comparison limitations

The existing nonempty shell_environment_policy.include_only list did not admit NODE_REPL_TRUSTED_SERVICES, although the stored MCP configurations contained the variable.

After appending that exact name and manually restarting the desktop app, the basic REPL returned:

MAC_NODE_REPL_STAGE_1 2026-09-11T19:26:18.677Z

This was not an isolated one-variable comparison. Alongside the restart, [mcp_servers.computer-use].enabled changed from true to false between phases. That legacy-server toggle's source and exact change time are unknown. The inspected node_repl definition was unchanged.

Therefore, I am reporting recovery after these changes—not proving that the allowlist edit alone caused it. This is a customized configuration, not a clean-profile reproduction.

Subsequent failures

All times below are September 11 UTC. Each test stopped on its first execution error.

Test window	Operation	Exact error
19:31:53–19:32:05	`cua_repl` Calculator request	`cua is not defined`
19:39:05–19:39:10	Documented `node_repl + @oai/sky` initialization/target access	`sky requires node_repl; configure NODE_REPL_TRUSTED_SERVICES`
19:57:43–19:57:48	`cua_repl` after a separate startup-banner allowlist experiment	`Browser use requires a trusted Node REPL browser service`

No native Mac Calculator state or imagery was returned. No new underlying JSON exception was established for these later errors.

What installed-source inspection established

Both installed Sky and browser clients require a callable nodeRepl.rpc before requesting their respective sky and browser services. Neither client creates that function. The observed errors correspond to those guards in the inspected files; the actual loaded bytes remain unverified.

Sky uses a Proxy, so the import may have completed before accessing sky.target triggered its guard. The combined call did not distinguish those stages.

The unified launcher supplies startup JavaScript through NODE_REPL_JS_BANNER; that code calls setupCUA(...), which installs the cua binding. Exposed tool descriptions do not establish that this startup code executed successfully.

Both stored service maps contain sky and browser entries. That does not establish effective worker delivery or complete schema compatibility. The version-matched REPL implementation that creates nodeRepl.rpc was not identified in the bounded source inspection.

Current state and Windows comparison

The NODE_REPL_TRUSTED_SERVICES allowlist addition remains. The separate NODE_REPL_JS_BANNER addition was rolled back at 19:59:18 UTC, with byte-for-byte verification against its pre-experiment configuration. Current worker state after rollback is unknown. The legacy server remains disabled. No bundled code or runtime functions were patched, and no guards were bypassed.

Windows 11 in Parallels, on the same displayed desktop version, successfully controlled Calculator through node_repl + @oai/sky. This provides a working reference, but is not a configuration-identical or platform-identical control.

Request for maintainers

What installs nodeRepl.rpc in this bundled Mac runtime, and what prerequisites govern its availability? Is there a supported diagnostic that identifies the actual launcher/worker and verifies this initialization without exposing credentials or weakening trust controls?

If a known configuration incompatibility or released fix explains these observations, please identify the exact supported change or desktop/runtime version. Please advise if the post-recovery missing-RPC findings should be tracked separately.

Further local experiments are paused. These tests do not establish resolution of process-spawning, memory, or long-session stability problems.

Update after installing desktop 26.908.40834: native control remains blocked

Retested on September 11 after updating to desktop About 26.908.40834. Installed bundle metadata reports build 8881; installed unified-computer-use is 26.908.40834, with bundled @oai/cua-repl 0.1.0. Installed metadata does not establish the exact worker bytes loaded.

Enablement clarification: An initial preflight incorrectly treated [mcp_servers.computer-use].enabled = false as a global native-feature disablement. That preflight made zero calls. Subsequent read-only inspection established that the enabled unified configuration selects the native computer surface and that its surface-selection path does not consult this legacy-server flag. The currently exposed tool documents native application access. No setting was changed to proceed.

At 2026-09-11 23:10:17–23:10:21 UTC, exactly one mcp__cua_repl.js invocation followed the current first-call instructions:

let calculator = await cua.getApp("Calculator");

Exact returned output:

cua is not defined

Reported tool duration: 0.1711 seconds. No Calculator state, screenshot, permission prompt, or UI interaction was returned or reached. The test stopped without retries, resets, alternate interfaces, manual bootstrap code, configuration changes, or further log inspection.

The existing custom environment allowlist remains: NODE_REPL_TRUSTED_SERVICES is admitted; the earlier NODE_REPL_JS_BANNER experiment remains rolled back. This is not a clean-profile reproduction.

Conclusion: The update did not restore native control in this tested configuration. This attempt establishes the missing documented cua binding—not recurrence of the earlier JSON exception or proof that the new implementation has the older nodeRepl.rpc failure.

Related symptom: #44724. A shared root cause is unconfirmed.

Please identify the supported diagnostic for why this version's documented cua binding is unavailable, and whether the new @oai/cua-repl implementation requires a documented configuration migration. Further local experiments are paused.

I can reproduce the same failure mode on Windows.

Environment:

Windows 11 x64
Codex Desktop: 26.908.4834.0
Codex CLI: 0.154.0-alpha.6.2
Bundled Node.js: 24.20.0
@oai/cua: 0.2.4
@oai/sky: 0.6.32
sandbox_mode: workspace-write
Windows sandbox: unelevated

Fresh reproduction timestamp:
2026-09-14 09:54:08.392 +02:00

User-visible error:

trusted Node process exited unexpectedly; kernel reset, rerun your request

The failure happens before browser navigation starts.

I reproduced it:

in my existing workspace
in a brand-new empty workspace
while targeting localhost
while targeting https://example.com

So this is not specific to the target site or workspace.

The correlated low-level error is:

SyntaxError: "undefined" is not valid JSON
at JSON.parse ()
at Object. (.../trusted-worker.js:19:33)

Node.js v24.20.0

The first abnormal event occurs immediately after the bundled Node runtime is started.

Relevant observations:

bundled Node executes normally (node.exe --version succeeds)
node_repl.exe itself can start
codex-computer-use.exe can start
normal user-installed Node also works
the Codex runtime directory is readable/executable by the current user
no correlated Access Denied / EPERM / EACCES event was present for this fresh failure
no Defender, AppLocker, Code Integrity, or Windows Application crash event was found in the failure window
host ACLs for the Codex runtime and ~/.codex/tmp are valid
the same Browser failure occurs in a new workspace, so it does not appear to be caused by project ACLs

For this reproduction, the trusted worker appears to reach the same failure described in this issue:

JSON.parse(process.env.NODE_REPL_TRUSTED_SERVICES)

with the value missing / undefined inside the trusted worker environment.

Timeline for the fresh run:

09:54:08.251 - Browser runtime request initiated
09:54:08.328/.332 - bundled cua_node node.exe processes started
09:54:08.392 - trusted-worker.js throws JSON.parse(undefined)
09:54:08.392 - trusted worker exits and the Browser call returns:
"trusted Node process exited unexpectedly"

No correlated sandbox ACL failure was logged during this specific attempt.

This therefore looks like the same environment/protocol initialization regression, now confirmed on Windows as well.

I have not modified Codex runtime files, ACLs, sandbox settings, or installed any workaround.

Navigation Menu

Repository navigation

[macOS][26.831.21537] cua_repl trusted worker drops NODE_REPL_TRUSTED_SERVICES and crashes before browser attachment #42757

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

In-app feedback

September 11 follow-up: basic REPL recovered; native Computer Use remains blocked

Environment

Minimal failing case before the configuration experiment

Partial recovery and comparison limitations

Subsequent failures

What installed-source inspection established

Current state and Windows comparison

Request for maintainers

Update after installing desktop 26.908.40834: native control remains blocked

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[macOS][26.831.21537] cua_repl trusted worker drops NODE_REPL_TRUSTED_SERVICES and crashes before browser attachment #42757

Description

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 4, 2026

ecv123 commented on Sep 5, 2026

ecv123 commented on Sep 5, 2026

ecv123 commented on Sep 7, 2026

In-app feedback

sunnkis commented on Sep 9, 2026

ecv123 commented on Sep 11, 2026

September 11 follow-up: basic REPL recovered; native Computer Use remains blocked

Environment

Minimal failing case before the configuration experiment

Partial recovery and comparison limitations

Subsequent failures

What installed-source inspection established

Current state and Windows comparison

Request for maintainers

ecv123 commented on Sep 11, 2026

Update after installing desktop 26.908.40834: native control remains blocked

maksdjab89 commented on Sep 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions