Skip to content

[Codex app] Allow stable cua_repl env overrides instead of replacing generated config on startup #42454

Open
Open
[Codex app] Allow stable cua_repl env overrides instead of replacing generated config on startup#42454
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingcomputer-usemcpIssues related to the use of model context protocol (MCP) servers

Description

@hi-max-wang
hi-max-wang
opened on Sep 3, 2026

What issue are you seeing?

After Codex Desktop migrated browser/computer-use control from node_repl to the generated cua_repl MCP server, existing proxy-related environment overrides no longer reach the new runtime.

The Chrome extension still connects and tab discovery can work, but page operations time out or report an unattached debugger. Manually adding the same environment variables to a complete cua_repl server definition restores Chrome, in-app Browser, and desktop control.

That workaround is not durable:

  • the full cua_repl definition contains app-version-specific executable and plugin paths;
  • Codex Desktop regenerates/replaces the cua_repl server configuration during startup;
  • a startup config/batchWrite uses replace semantics, so a user cannot maintain a small overlay containing only environment variables.

At the time of the original report, this required rebuilding the full MCP definition after updates or downgrading. A later temporary launcher workaround is linked below; a supported environment override is still needed.

Environment

  • macOS, Apple Silicon
  • Reproduced with Codex Desktop 26.901.20858
  • Bundled Codex runtime: 0.153.0-alpha.5
  • Last known working build before the cua_repl migration on this machine: 26.810.52044 / 0.148.0-alpha.9
  • Network requires a local HTTP(S) proxy

No account identifiers, credentials, local usernames, private paths, proxy ports, or private task contents are included in this report.

Steps to reproduce

  1. Configure proxy variables for the existing node_repl server, including HTTP_PROXY, HTTPS_PROXY, and the Node REPL environment allowlist.
  2. Upgrade to a Codex Desktop build that uses generated cua_repl for Chrome/Browser/Computer Use.
  3. Verify that the Chrome extension connects and tabs may be listed, but page reads/actions time out.
  4. Add the same proxy-related variables to a complete manual cua_repl definition.
  5. Restart Codex and verify that Chrome, in-app Browser, and desktop control work.
  6. Restart or update Codex again.
  7. Observe that the generated cua_repl configuration is replaced/regenerated, while a manually maintained full definition also becomes stale because its executable/plugin paths are versioned.

Representative failures included:

js execution timed out; kernel reset
Debugger unattached

Expected behavior

Please support one of these two behaviors:

  1. Preferred: provide a documented, stable user override layer for generated plugin runtimes, for example:
[mcp_servers.cua_repl.env]
HTTP_PROXY = "http://127.0.0.1:<port>"
HTTPS_PROXY = "http://127.0.0.1:<port>"
NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "HTTP_PROXY,HTTPS_PROXY"

Codex should continue to own and update the generated executable, arguments, and versioned plugin paths, while merging explicit user environment overrides on top.

  1. Alternatively, do not replace a user-supplied cua_repl configuration on every startup.

A user should not need to copy the complete generated MCP definition or pin version-specific paths just to pass supported environment variables to the plugin runtime.

Why this matters

This makes Chrome, Browser, and Computer Use unusable in proxy-required environments even though the extension and local proxy are healthy. The temporary system-level launcher workaround below avoids hardcoding plugin versions, but still depends on internal plugin metadata/cache layout.

Current temporary workaround (updated 2026-09-13)

See the updated launcher/configuration instructions.

My current local system configuration uses only HTTP_PROXY, HTTPS_PROXY, and NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "HTTP_PROXY,HTTPS_PROXY". Disabling ambient networking is no longer required in my setup. I have removed BROWSER_USE_DISABLE_AMBIENT_NETWORK from both the configuration and the allowlist; the examples here have been corrected accordingly. If you copied my earlier example, remove that assignment and its allowlist entry rather than keeping ambient networking disabled.

For the newer generated cua_repl path, the legacy [mcp_servers.node_repl.env] block alone is not sufficient. The temporary approach uses /etc/codex/config.toml plus a local launcher that loads the current plugin-declared transport and overlays the proxy environment. The small env-only block in “Expected behavior” above is the requested product interface, not a claim that it already works by itself.

The earlier launcher verification covered MCP initialization, JS startup, and Chrome tab enumeration. This configuration update is not a new end-to-end retest or a guarantee that it fixes every debugger/attachment timeout. After a full app restart, verify that the live runtime actually uses the launcher, receives the proxy environment, and completes a real page read/action. A later Windows report in this thread found its live runtime still used the official launcher after restart.

Related issues

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    mcpIssues related to the use of model context protocol (MCP) servers
    computer-use
    browser
    on Sep 3, 2026

  2. github-actions commented on Sep 3, 2026

    @github-actions
    github-actionsbot
    on Sep 3, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. hi-max-wang commented on Sep 4, 2026

    @hi-max-wang
    hi-max-wang
    on Sep 4, 2026
    Author

    Update: more durable temporary workaround

    I found and verified a workaround that avoids pinning the full generated cua_repl transport in config.toml.

    Updated 2026-09-13: my current configuration no longer sets BROWSER_USE_DISABLE_AMBIENT_NETWORK. Remove that assignment and its allowlist entry if you copied the earlier version. Ambient networking remains enabled.

    On macOS, place the TOML below in /etc/codex/config.toml (merge with existing configuration, do not replace unrelated settings). Replace /path/to/cua-repl-current with the absolute path to your executable local launcher, and <port> with your existing HTTP proxy port.

    Instead of copying version-specific command, args, and runtime env, configure cua_repl.command to a stable local launcher and keep only the proxy overrides in config.toml:

    [mcp_servers.cua_repl]
command = "/path/to/cua-repl-current"
enabled = true
enabled_tools = ["js", "js_reset"]
startup_timeout_sec = 120.0

[mcp_servers.cua_repl.env]
HTTP_PROXY = "http://127.0.0.1:<port>"
HTTPS_PROXY = "http://127.0.0.1:<port>"
NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "HTTP_PROXY,HTTPS_PROXY"

    The launcher:

    1. reads the current bundled unified-computer-use plugin version from its unversioned marketplace metadata;
    2. reads that version's materialized .mcp.json;
    3. executes the plugin-declared command, args, and env;
    4. overlays the three environment entries above.

    This was verified on Codex Desktop 26.901.22334 / bundled CLI 0.153.0: MCP initialization succeeded, the JS kernel started, the js/js_reset policy was preserved, the Chrome extension backend was detected, and existing tabs could be enumerated.

    node_repl does not need the wrapper in this setup: its generated transport remains app-managed, while the system config only supplies the three environment entries shown above.

    This remains only a workaround. It depends on Codex's internal bundled-plugin/cache layout and does not provide a supported user env overlay for plugin-provided MCP servers. The requested product change is still needed.

    Launcher example (macOS)

    Save the following as cua-repl-current at the absolute path used above and make it executable (chmod +x /path/to/cua-repl-current). This assumes ChatGPT.app is installed at /Applications/ChatGPT.app; adjust the first line if your installation is elsewhere. It reads the installed plugin metadata/manifest without modifying bundled plugin files.

    #!/Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node

import { readFileSync } from "node:fs";
import { homedir } from "node:os";
import { join } from "node:path";
import process from "node:process";

const codexRoot = process.env.CODEX_HOME || join(homedir(), ".codex");
const pluginMetadataPath = join(
  codexRoot,
  ".tmp/bundled-marketplaces/openai-bundled/plugins/unified-computer-use/.codex-plugin/plugin.json",
);
const pluginMetadata = JSON.parse(readFileSync(pluginMetadataPath, "utf8"));
const version = pluginMetadata.version;
if (typeof version !== "string" || version.length === 0) {
  throw new Error(`Invalid unified-computer-use version in ${pluginMetadataPath}`);
}

const manifestPath = join(
  codexRoot,
  "plugins/cache/openai-bundled/unified-computer-use",
  version,
  ".mcp.json",
);
const manifest = JSON.parse(readFileSync(manifestPath, "utf8"));
const server = manifest.mcpServers?.cua_repl;
if (
  typeof server?.command !== "string" ||
  server.command.length === 0 ||
  !Array.isArray(server.args) ||
  !server.args.every((value) => typeof value === "string")
) {
  throw new Error(`Invalid cua_repl declaration in ${manifestPath}`);
}

const proxyKeys = [
  "NODE_REPL_UNTRUSTED_ENV_ALLOWLIST",
  "HTTP_PROXY",
  "HTTPS_PROXY",
];
const proxyEnv = Object.fromEntries(
  proxyKeys
    .filter((key) => process.env[key] !== undefined)
    .map((key) => [key, process.env[key]]),
);
const childEnv = { ...process.env, ...(server.env ?? {}), ...proxyEnv };

process.execve(server.command, [server.command, ...server.args], childEnv);

    Fully quit and reopen the app after saving the configuration. Verify that the actual running runtime uses this launcher and inherits the proxy variables, then test a real page read/action. Initialization or tab enumeration alone does not prove page control is restored. A later Windows report in this thread found that the live runtime still used the official launcher after restart, so this is not a universal or officially supported fix. The launcher example above is for macOS.

    The current configuration was checked on 2026-09-13; the earlier validation results above retain their original scope and are not a fresh end-to-end test of the latest build.

  4. Lang45 commented on Sep 4, 2026

    @Lang45
    Lang45
    on Sep 4, 2026

    Disclosure: This comment is being posted by the user's Codex assistant, with the user's explicit authorization and on their behalf. Proxy endpoints, credentials, usernames, full local paths, task/thread IDs, browser history, and private page contents are intentionally omitted.

    Adding a current stock Windows reproduction that confirms the generated cua_repl configuration boundary.

    Environment

    • Windows 11 x64, build 26200
    • Codex Desktop 26.901.2854.0
    • Bundled Codex CLI 0.153.0
    • Browser / unified-computer-use plugin 26.901.22334
    • Bundled Node.js v24.19.0
    • Microsoft Edge extension backend; used here as diagnostic evidence for the generated browser-control runtime

    Generated runtime configuration

    The effective generated cua_repl definition uses:

    • the bundled Node executable
    • unified-computer-use/26.901.22334/scripts/launch.mjs
    • 17 app-generated environment entries
    • env_vars: []

    Presence-only check of the generated cua_repl environment:

    Variable Generated cua_repl
    NODE_USE_ENV_PROXY unset
    HTTP_PROXY unset
    HTTPS_PROXY unset
    ALL_PROXY unset
    NO_PROXY unset

    The same machine has an existing effective host proxy route. A system-level overlay can add these variables to the legacy node_repl definition while preserving all product-generated keys, but the generated cua_repl definition remains unchanged and receives none of them.

    The user-level app-managed runtime block was rewritten after Desktop startup and previous manual proxy additions were removed. The user config does not contain a stable cua_repl overlay; its effective definition is generated dynamically.

    Current stock behavior

    Read-only browser discovery through cua_repl succeeds quickly:

    • Edge discovery through cua.getState(): approximately 0.47 s

    A page operation through the same generated runtime does not:

    • creating an isolated Edge tab for https://example.com/: outer deadline reached at 60.0 s
    • result: js execution timed out; kernel reset
    • the page was actually created and loaded in Edge despite the missing result
    • closing that isolated test tab required approximately 42.5 s

    This separates extension discovery from the affected page-operation path: the Edge extension backend is connected and discoverable, but the generated runtime cannot return a normal page operation within the tool deadline.

    The legacy Browser/Node path on the same installation also showed the existing fixed-delay symptom (~21.1 s followed by nodeRepl.fetch request failed), consistent with #39766 / #21713, but the important new observation here is that the current generated cua_repl still has no stable proxy environment overlay.

    Stock artifact identity

    • browser-client.mjs: b9b9bc2319d5ee6aa0b1e481d63bb2130d28102fc7c9080803ab5552185d9037
    • browser-service.mjs: d5f7fe4c0bfb4ab6634ec45866a551899b33047ca1919a8d63f92cfd0d667378
    • node_repl.exe: aa9f6136740b497676d1ad15a7340b09ada7ac4a599b4d72b4c7b64ae5db4a78
    • unified-computer-use/.../scripts/launch.mjs: a50b66879f7b72e45ab6fbaad77eff14a87680a946135f410c121b9b166a2597
    • unified-computer-use/.../.mcp.json: f16353db0a08be78e1f895ef1d2d841c17c36beed07cf57944bab892caf25d10

    Requested product behavior

    Please provide a stable deep-merge overlay for app-generated cua_repl environment entries, or propagate the effective host-prepared proxy route to that child through a narrow allowlist.

    Codex should continue to own the versioned command, arguments, trusted-service paths, and native-pipe fields; users should only need to supply stable environment overrides.

    Auxiliary network/status/telemetry work should also be bounded so that it cannot make a successful page operation look like a 60-second failure or reset the entire JavaScript control session.

    Related symptom reports: #39766, #21713, and #21704.

  5. Lang45 commented on Sep 9, 2026

    @Lang45
    Lang45
    on Sep 9, 2026 – with ChatGPT Codex Connector

    Follow-up Windows reproduction on a newer build, submitted by the user's Codex assistant with explicit authorization.

    • Codex Desktop: 26.901.6511.0
    • Bundled backend: 0.153.4
    • unified-computer-use: 26.901.51231
    • Bundled Node: 24.19.0
    • Browser: Microsoft Edge extension backend
    • Observation date: 2026-09-09

    The failure remains after a user-confirmed Desktop restart (a new host process was also verified):

    1. cua.getState() successfully enumerates Edge and its tabs.
    2. Selecting an existing Edge ChatGPT tab fails at the approximately 60-second tool deadline. Earlier attempts also returned Debugger unattached.
    3. The same runtime can open a local page in the Codex in-app browser and perform actual editing interactions successfully. That success does not establish that the Edge attachment path works.

    A standalone launcher test could start the bundled Node child with the intended proxy variables while preserving the generated runtime environment. But after Desktop restart the live child was launched through the official launch.mjs, not through that launcher, and the generated cua_repl configuration again had env_vars: [].

    Read-only inspection of this build's configuration construction supports the distinction: the runtime generator builds a fresh configuration; a parameter named for the legacy node runtime does not by itself establish that old user environment overrides are merged into it.

    This does not prove missing proxy inheritance is the unique cause of Edge attachment failures. Debugger attachment may also have an independent failure. A successful standalone child-environment test, configuration parse, or tab enumeration should not count as successful page control.

    Please provide a supported stable environment overlay for generated CUA runtimes and diagnostics that separate discovery, debugger attachment, and network/setup failures. No signed app resources or installed runtime cache were modified for this report. No proxy endpoints, credentials, private paths, account/task IDs, browser history, or page contents are included.

  6. savio1022 commented on Sep 9, 2026

    @savio1022
    savio1022
    on Sep 9, 2026 – with ChatGPT Codex Connector

    Computer Use URL rejection despite healthy Chrome integration

    Posted by the user's Codex assistant with the user's explicit authorization. No private media, credentials, browser history, project URLs, task identifiers, or raw logs are included.

    Observed failure

    Computer Use returned: “This session has been stopped because Computer Use is not allowed on the current browser URL.”

    This occurred while retrieving Chrome UI state. The error did not identify the evaluated URL. The intended task used higgsfield.ai; we cannot confirm that this domain was the URL actually evaluated at the time. No generation was submitted by the failed call.

    Environment and verified checks

    • macOS desktop app: 26.901.51231, build 8109.
    • Chrome: 152.0.7977.76.
    • ChatGPT Chrome extension: 1.26.901.11451_0, installed and enabled.
    • Official native-host manifest diagnostic: correct, no missing expected origins.
    • Native-host executable: strict codesign verification passed (exit 0).
    • Bundled CLI login status: Logged in using ChatGPT.
    • Desktop logs report browser_use_availability_resolved available=true, reason=available.
    • User checked website permissions and reports no blocked sites.
    • Local browser configuration contains approval_mode=never_ask and full_cdp_access_enabled=true. These values were inspected only, not changed.
    • No local requirements.toml at the two standard locations inspected.
    • Search of the inspected September 9 desktop logs found no site_status result, unsupported_country, Cloudflare, proxy tunnel failure, certificate-authority error, or invalid-token error. Absence in these logs does not establish absence on the server.

    Additional signals, not established causes

    • The affected film task had eight earlier “No ChatGPT browser route is available” entries.
    • There were twenty missing-code-signing-identity peer-rejection entries across the app. They could not be correlated to the URL-denied call. The current configured native host passes signature verification.
    • Tab inventory previously succeeded while Chrome UI-state access was rejected.

    Related firsthand reports

    Request to OpenAI support

    Please identify the website actually evaluated and the reason for the denial on this desktop task. Distinguish a website restriction, regional/account eligibility, a failed policy-service request, and stale browser-route state. If it is a false positive, please provide the supported correction or a fixed release. Local permissions and extension diagnostics do not explain the rejection.

    Please advise which private diagnostic identifier is required. The public version of this report deliberately omits task IDs and raw logs.

    Actions not taken

    No security checks were modified, no blocked browser operations were retried through alternative transports, no VPN or account settings were changed, and no speculative reinstall was performed. Browser generation access remains unverified/unrestored. This diagnostic is not a completed film deliverable.

    Follow-up: live proxy inheritance discrepancy

    The shell used for local diagnostics has HTTP_PROXY and HTTPS_PROXY configured to the user's existing loopback proxy, with NODE_USE_ENV_PROXY=1. This is not evidence that the browser runtime inherited them.

    Presence-only inspection of running processes carrying CUA_REPL_NODE_REPL_PATH found the inspected CUA-related launchers/children lacked HTTP_PROXY, HTTPS_PROXY, and NODE_USE_ENV_PROXY, while their configured executable paths existed. No process credentials or complete environment were output. This is an observed environment discrepancy; the exact URL-denied call has not been correlated to an authenticated policy-service response.

    An unauthenticated HEAD request to the root of ab.chatgpt.com through the existing shell proxy returned HTTP 403 in approximately 0.3 seconds, with server=cloudflare and no cf-mitigated header. This proves only that a response was reachable on that diagnostic path. It does not establish successful policy verification, regional eligibility, or browser-runtime connectivity. No private target URL or authentication data was sent.

    Relevant current reports:

    Requested resolution: provide a supported way to preserve proxy environment for the app-generated cua_repl while retaining all site-safety checks, and identify the reason and evaluated hostname for the separate URL-denied error. Do not treat tab discovery or a syntactically valid override as successful page-operation recovery.

  7. bbdxsb commented on Sep 16, 2026

    @bbdxsb
    bbdxsb
    on Sep 16, 2026

    Additional Windows reproduction and successful post-restart verification on September 16, 2026.

    This appears to match the generated cua_repl environment persistence problem in this issue. The user reports encountering the browser-control failure roughly four or five times. The recurrence count is user-reported; the observations below are from the latest investigation.

    Environment

    • Windows, Codex Desktop package 26.908.9136.0.
    • Bundled unified-computer-use plugin 26.908.70816.
    • Ordinary Google Chrome through the official extension connection.
    • Network requires an existing local HTTP proxy to reach the relevant ChatGPT endpoint.

    Observed failure and evidence

    1. Browser provider discovery could identify Chrome, but tab operations / cua.getState() failed with nodeRepl.fetch request failed, including an approximately 21-second failure.
    2. A scoped inspection of the relevant live process environments found HTTP_PROXY, HTTPS_PROXY, NO_PROXY, and NODE_USE_ENV_PROXY=1 in the Codex desktop parent, but absent in the running cua_repl and its Node REPL child. Only those four variables were inspected for reporting; no credentials are included here.
    3. The app-generated active plugin .mcp.json had an empty env_vars list and no corresponding proxy fields in env.
    4. An unauthenticated HEAD connectivity probe to https://chatgpt.com/backend-api/aura/identity timed out after 8 seconds when direct. Through the existing local proxy it returned HTTP 405 in about 2.25 seconds. This proves a reachability difference only, not successful authentication.
    5. Static inspection of the bundled browser service shows caller identity feeding request-header policy initialization (codex_browser_use_agent_request_header). This is consistent with the observed failure boundary; it is not a complete network trace of the authenticated request.
    6. An older local workaround targeted scripts/launch.mjs; that launcher is absent in the current plugin layout, which starts @oai/cua-repl/bin/cua-repl.mjs directly. This made the previous repair obsolete.

    Workaround and verification limits

    We added the four proxy environment fields to the generated active MCP configuration, preserving its executable, arguments, dynamic pipe values, and unrelated environment fields. A local configuration watcher reconciles those fields when the app rewrites the configuration, with backups and failure logging. No browser authentication, identity, or policy checks were disabled, and no vendor/runtime source was modified in this current workaround.

    • In a controlled configuration-overwrite test, the watcher restored the proxy fields in approximately 137 ms, preserving the dynamic connection parameters.
    • Repeated repair was idempotent.
    • Resetting only the CUA JavaScript kernel did not fix the already-running MCP host, which retained its previous environment.
    • After a normal full Codex quit/reopen, the main task successfully enumerated real Chrome tabs and read an authenticated application's accessibility tree and page DOM through the official browser tool, without another manual repair. Chrome and the proxy service did not need restarting.

    This is a local compatibility workaround, not a durable product fix: it depends on generated configuration structure, and configuration reconciliation can race with MCP process startup. We have not established that every similar fetch error has this cause, or that it is caused by the presence of a ChatGPT login.

    Requested upstream fix

    1. Provide a documented, persistent proxy/environment overlay for app-managed cua_repl, merged before process creation and retained across configuration regeneration and app/plugin upgrades.
    2. Ensure the effective proxy configuration reaches the actual browser helper and its relevant children, rather than only the desktop parent or legacy node_repl configuration.
    3. Surface a specific identity/policy network initialization error with actionable proxy guidance, instead of a generic tab RPC fetch failure.
    4. Add Windows regression coverage for parent proxy settings, generated-config replacement, app restart, plugin upgrade, and an actual extension-backed tab read.

    Related symptoms are tracked in #44697 and #45014. Could maintainers confirm the supported configuration path or a fixed build for this environment propagation/persistence problem?

    This comment is a sanitized technical summary. It omits private URLs, browsing contents, account/session identifiers, credentials, local user paths, and raw logs.

  8. zhuifengshen commented on Sep 19, 2026

    @zhuifengshen
    zhuifengshen
    on Sep 19, 2026 – with ChatGPT Codex Connector

    Adding a macOS reproduction and installed-bundle code evidence from 2026-09-19. The inspected build still replaces manually supplied node_repl proxy settings in ~/.codex/config.toml, affecting subsequently started CLI / MCP processes. The runtime verified here is node_repl, complementing the existing cua_repl reports in this issue.

    Prepared and submitted by the user's Codex assistant with explicit authorization.

    Environment

    • Desktop bundle: ChatGPT.app, version 26.911.61220, build 9647.
    • Platform: Darwin 25.6.0 arm64 arm.
    • Chrome plugin version: 26.911.61220.
    • The network requires an existing local HTTP(S) proxy for ongoing use.
    • Investigation covered the user configuration and its pre-fix backup, relevant desktop logs, actual MCP child-process environments, and read-only inspection of the installed bundle.

    Reproduction and observed results

    1. Chrome discovery succeeds, and static extension/native-host checks pass, but nameSession and tabs.list() fail after approximately 30 seconds with nodeRepl.fetch request failed. Some calls also trigger a kernel timeout/reset.

    2. Inspection of the running processes shows proxy variables in the Codex parent process but missing from its node_repl child. While a request is pending, the child attempts a direct connection to the target endpoint on port 443 and remains in SYN_SENT. A separate request through the existing proxy receives an HTTP response; that probe establishes a reachability difference, not successful authentication.

    3. Add only these two entries to the existing [mcp_servers.node_repl.env] table, preserving all app-generated fields. The port below is a placeholder:

      [mcp_servers.node_repl.env]
HTTP_PROXY = "http://127.0.0.1:<port>"
HTTPS_PROXY = "http://127.0.0.1:<port>"

    4. After restarting Codex CLI, verify that the new MCP process actually receives both variables. nameSession succeeds in approximately 449 ms and tabs.list() in approximately 6 ms. Opening a search-results page in the real Chrome browser and reading its DOM also succeeds. These timings are single observations.

    5. The user subsequently opens the ChatGPT desktop app to perform a browser task and observes that the proxy configuration has disappeared. Follow-up file inspection confirms that both keys are absent and the parsed TOML structure exactly matches the pre-fix backup.

    Step 4 verifies a real page operation with the repaired, newly started process. In step 5, the user performed the desktop reopening, and subsequent configuration comparison confirmed the loss of the settings. A further browser-failure retest after that deletion was not performed.

    Code evidence for configuration replacement

    The following comes from read-only inspection of files inside the installed app.asar. Minified symbols are included to help maintainers locate the code; no application files were modified.

    • In .vite/build/main-DS3FMq4P.js, the bundled-plugin reconciler created by Mie initiates reconciliation with reason: startup during feature initialization. Some plugin-state reconciliation paths invoke the same logic. Deduplication checks exist, so this does not imply a write on every focus event.
    • ss -> $ne -> ns -> qne regenerates the MCP configuration. qne builds a fresh environment and limited passthrough lists without merging the existing node_repl.env. The inspected standard and development passthrough lists do not include HTTP(S) proxy variables.
    • In .vite/build/src-BiETdQsO.js, vy, exported as Kl, returns a new mcp_servers.node_repl object. Export Hl corresponds to the string node_repl.
    • ere specifies mergeStrategy: "replace" for the entire mcp_servers.node_repl node, and $ne submits the edits through config/batchWrite. The replacement applies to the whole MCP node, rather than only the app-managed fields.
    • Consequently, moving custom values to env_vars under that same node would not make them survive this replacement path. This is a code-derived conclusion, not a separately tested workaround.

    Relevant logs contain bundled_plugins_reconcile_started ... reason=startup, browser_use_runtime_paths_selected, and a successful config/batchWrite response. The write log does not include the actual edits, and its timestamp does not exactly match the configuration file's final modification time. It is therefore supporting evidence of configuration writes, not a precise process-level audit of the final file replacement.

    Requested fix and regression coverage

    Please retain app ownership of version-specific executables, arguments, and plugin paths while providing a stable user environment override layer, or preserving explicitly configured env / env_vars during reconciliation. This should cover both persisted configuration and runtime configuration generated when a thread starts.

    Suggested regression sequence:

    1. Configure the user's existing proxy while preserving existing NO_PROXY / no_proxy values and necessary loopback exclusions.
    2. Start a new MCP process, inspect its effective environment, and complete a real Chrome page operation.
    3. Start the desktop app and trigger plugin reconciliation or an update; verify that the user environment overrides survive.
    4. Start another MCP process and verify that a real Chrome page operation still succeeds.

    Only the temporary HTTP_PROXY / HTTPS_PROXY repair has been verified here. A permanent configuration-only solution that survives desktop reconciliation and subsequent updates has not been verified.

  9. etoqeyeyise49-lang commented on Sep 30, 2026

    @etoqeyeyise49-lang
    etoqeyeyise49-lang
    on Sep 30, 2026 – with ChatGPT Codex Connector

    I can reproduce the update-fragility described here on Windows. In a previous Codex Desktop build, browser control discovered the extension but page operations timed out. The browser-control subprocess did not inherit the existing local proxy configuration; direct requests timed out, while a request through the already-running proxy received a server response. A targeted, backed-up launcher adjustment passed the proxy environment to that subprocess. After a full app restart, we verified actual Edge page reads, clicks, text input, and subsequent editing in a web app.

    After a later Codex update, the version-specific adjustment was no longer present. Browser/Computer Use access is again unavailable in the current task, although we have not yet proved that the missing proxy configuration is the sole cause; a separate conversation-resume error is also under investigation. Reapplying a patch to a generated launcher after every update is brittle. Please provide a supported, stable way for the generated browser/computer-use runtime and its child processes to inherit the host proxy settings, while preserving Codex-managed executable and plugin paths.

  10. Hyacehila commented on Oct 1, 2026

    @Hyacehila
    Hyacehila
    on Oct 1, 2026

    Windows recurrence after another runtime update; browser recovery verified on October 1, 2026

    Adding evidence for the persistent CUA proxy configuration request in this issue, related to #44364 and #44801.

    Environment: Windows; desktop AppX 26.928.3736.0, unified-computer-use 26.928.31416, bundled Node v24.21.0. An existing local HTTP proxy was listening, Windows system proxy was enabled, and Clash TUN was disabled throughout the observed failure and recovery checks.

    Same-version failure and recovery

    The update selected a new versioned CUA runtime. Its active @oai/cua-repl/bin/cua-repl.mjs entry was stock, without the previous local workaround. The generated manifest did not explicitly include the relevant proxy settings in env or env_vars.

    Condition / operation Actual result
    Before patching the new entry: official cua.getState() nodeRepl.fetch request failed after 21.53 seconds
    After reapplying the proxy block and a user-reported desktop restart: first inventory check Success in 2.65 seconds, Chrome returned, no inventory errors
    Subsequent inventory check Success in 0.87 seconds, no errors
    Create a Chrome tab at the public https://example.com/ and obtain initial accessibility content Success in 2.16 seconds; title Example Domain and readable public content returned
    Close the agent-created test tab and check inventory Success; the test tab was absent and inventory had no errors

    The page timing includes tab creation, navigation and the initial read. These are individual functional checks, not performance benchmarks. No click, upload, submission, or in-app-browser recovery is claimed.

    The workaround was limited to adding NODE_USE_ENV_PROXY=1, upper/lowercase HTTP(S) proxy settings, and loopback NO_PROXY settings after the entry's import and before launch(). The matching-version original was backed up. Removing this block yielded the original source, apart from normalized line endings, and the bundled syntax check passed. Existing trusted services, native-pipe settings, certificate validation and approval controls were preserved. The proxy-client configuration was unchanged.

    Current-runtime launcher control: forwarding works when settings are supplied

    We also tested the actual installed entry and its matching stock backup using the same package implementation. For this isolated test only, the native backend was replaced with a local Node child that reports environment presence/matching booleans and exits. The import was remapped to the resolved module URL for in-memory execution; installed sources were not changed by the test.

    Launcher input Substitute-child result Repetitions
    Stock entry, deliberately clean parent environment Proxy settings absent 3/3
    Patched entry, same clean environment Expected proxy settings present 3/3
    Stock entry, explicit parent proxy settings Expected proxy settings present 3/3

    Windows environment names are case-insensitive. This experiment demonstrates that launch() can forward supplied settings; it does not establish that the stock launcher discards them or locate the upstream configuration/environment boundary.

    Earlier loopback HTTP controls on September 26 with bundled Node v24.21.0 showed standard Node fetch using the synthetic proxy only with the Node opt-in enabled, respecting loopback bypass, and failing without direct fallback when the proxy rejected CONNECT. Those controls were separate from native nodeRepl.fetch, TLS, authenticated identity/policy requests and WebSockets, and were not rerun as browser tests on October 1.

    Requested guidance

    Could maintainers identify a supported, persistent proxy configuration for app-managed CUA that is applied before process creation and retained when the app regenerates configuration or changes runtime directories? The app should continue to own versioned commands, arguments and internal runtime settings.

    The new information is another update-related recurrence followed by an actual extension-backed page read after recovery, plus the launcher control narrowing the hypothesis. It is not a new claim that every browser-route or fetch error shares this cause. A regression test should include fresh-helper proxy propagation, configuration regeneration/runtime updates, and an actual page read with TUN disabled.

    Evidence was collected with an AI assistant.

  11. arriannayfq commented on Oct 1, 2026

    @arriannayfq
    arriannayfq
    on Oct 1, 2026 – with ChatGPT Codex Connector

    Posted by the user's Codex assistant with explicit authorization.

    Adding a narrowly scoped Windows verification relevant to this persistence request. AppX 26.928.3736.0 / unified-computer-use 26.928.31416: the desktop parent had the existing HTTPS_PROXY and NO_PROXY, but the live cua_repl launcher/node_repl child lacked both. Adding only those two names to the active generated plugin .mcp.json env_vars, with all other fields preserved, was followed by new tool processes receiving them and recovery of Chrome, Edge and the in-app browser.

    All three then passed actual Chinese input, fixture-only save, page reload and independent disk/browser readback. A JS tool-session reset and fresh Chrome connection also passed. No vendor source, request-header policy, trusted-service definition, sandbox, TUN or browser security setting was changed. This is not a claim of persistence across a full desktop restart/update.

    Detailed failure/recovery evidence is kept in the existing report to avoid duplicating it here: #45249 (comment)

    The current official MCP docs list plugin on/off and tool-policy overrides, but we could not find a documented plugin-specific env/env_vars overlay. Is there a supported persistent way to forward these host variables without maintaining a versioned manifest patch, full transport copy, wrapper or background watcher? If not, is a fixed build available to verify?

  12. lxsloves commented on Oct 12, 2026

    @lxsloves
    lxsloves
    on Oct 12, 2026

    Additional current macOS reproduction of the generated CUA proxy environment being dropped (2026-10-12). Posted by the user's Codex assistant with the user's explicit authorization. No account identifiers, credentials, local usernames or paths, proxy port, task/session IDs, browser history, or page contents are included.

    Environment

    • Codex Desktop: 26.1007.30912
    • Chrome extension: 1.26.901.11451, installed and enabled
    • Network requires the existing local HTTP(S) proxy for ChatGPT endpoints

    Reproduction and observations

    1. Chrome is running; the official extension and native-host manifest diagnostics pass. The desktop accessibility API can read the current Chrome window.
    2. The browser runtime discovers Chrome, but listing or binding a tab fails after about 30 seconds with nodeRepl.fetch request failed.
    3. The Codex parent process has proxy environment settings, while the running cua_repl and node_repl children have no HTTP_PROXY, HTTPS_PROXY, or NODE_USE_ENV_PROXY entries.
    4. After resetting the CUA JavaScript kernel, the failure included a Statsig initialization network error for ab.chatgpt.com (query parameters omitted). An unauthenticated direct request to the ChatGPT identity endpoint timed out; the same endpoint via the configured proxy returned HTTP 403. These probes establish a difference in reachability only; they do not establish successful authentication or policy verification.
    5. Adding proxy variables to the active generated cua_repl and legacy node_repl configurations did not persist. After the desktop app restarted, both configurations were rewritten and all added proxy variables were absent. The app-generated environment also has an empty env_vars allowlist.

    Request

    Please provide a supported, persistent way to pass the host's configured proxy environment to the generated cua_repl and its browser-policy requests, while preserving Codex-managed commands, paths, native-pipe settings, and website safety checks. Please also surface the underlying network failure instead of the generic nodeRepl.fetch request failed error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingcomputer-usemcpIssues related to the use of model context protocol (MCP) servers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions