Windows Codex 26.527 package includes Browser/Computer Use but runtime gate exposes only latex

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

• #24252
• #24188

Powered by Codex Action

Codex duplicate triage:

I reviewed the duplicate bot suggestions (#24252 and #24188). They look related, but I do not think this issue should be closed as an exact duplicate yet.

• #24252 is a macOS 26.519 restart/session-sync report where the runtime marketplace keeps browser and latex, then prunes chrome and computer-use; logout/login temporarily restores them.
• #24188 is a macOS/regional/account eligibility report from Lebanon where Computer Use disappears or shows a disabled-by-org/region state; the runtime marketplace generally keeps browser and latex.
• This issue is Windows-specific on Codex app 26.527, where the Windows Store package contains browser, chrome, computer-use, and latex, but the desktop availability resolver logs reason=statsig-disabled and the generated runtime marketplace exposes only latex. Browser Use itself is pruned too.

So this appears to be in the same broader eligibility/Statsig/runtime-marketplace family, but this report adds Windows 26.527 evidence, a same-version working Windows machine comparison, and the browser_use_availability_resolved ... reason=statsig-disabled log path.

Note: this update was drafted and posted by Codex on behalf of the user, based on additional local diagnostics and a same-network machine comparison.

Refining the earlier diagnosis: I would no longer describe this as simply "region-gated".

Both Windows machines are reportedly on the same network, with the same account and the same Codex Store package/version, but they receive different availability outcomes:

• Broken machine: browser_use_availability_resolved available=false ... reason=statsig-disabled
• Working machine: browser_use_availability_resolved available=true ... reason=available

The broken machine also cannot use Browser/Chrome/phone pairing, while the other machine can. Since the network is the same, this is less likely to be a simple public-IP geolocation block.

A more precise hypothesis is:

Same account, same app package, same network, but one Windows machine receives statsig-disabled and cannot use Browser/Chrome/phone pairing, while the other receives available. This suggests a server-side device/account rollout or eligibility-state mismatch, not missing local files or a simple network geolocation issue.

Additional update: general Windows Computer Use was locally recovered on the broken machine by setting the packaged Windows diagnostic override:

[Environment]::SetEnvironmentVariable('CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE','1','User')

After relaunch, logs showed computer-use added to the runtime marketplace and the native pipe becoming ready. A live action test verified Codex could launch Calculator, enter an expression, and read back the result. However, Browser/Chrome/phone pairing remained unavailable and Browser Use continued to log reason=statsig-disabled.

So the current split is:

• Windows Computer Use: locally working via CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1
• Browser Use / Chrome control / phone pairing: still blocked by the remote availability path on this specific machine/device state

This points to the remaining bug being in server-side feature eligibility evaluation, cached device/install state, or rollout assignment for this machine, rather than the installed package or local bundled plugin files.

Attribution: this follow-up was prepared from local diagnostics and posted by Codex on behalf of the user.

Follow-up: Remote Connections / phone pairing appears blocked by the same server-side desktop-feature gate on this Windows device

Same machine as the Browser/Computer Use report:

Codex Windows Store package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
Desktop release: 26.527.31326
OS: Windows 11; locale en-US; timezone UTC+07:00 (Hanoi); region: Vietnam

Symptom

The Connections settings page is entirely absent from Settings on this device. The Settings sidebar goes roughly Hooks -> Git -> Environments, with no Connections entry and no Profile entry. There is therefore nowhere to start the phone-pairing / remote-control setup or scan a pairing QR.

A second Windows device on the same ChatGPT account, same Store package, and same network shows the Connections page normally and can pair. So this does not look like missing local files or simple public-IP geolocation. It looks like a per-device eligibility/rollout difference.

Code-level finding

Desktop feature flags default off in the main bundle, including:

control: false,
deviceAttestation: false,

The only ungated production override found is:

CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1

That flips only computerUse / computerUseNodeRepl, which explains why general Windows Computer Use can now work on this device.

For Remote Connections, the renderer feature-resolution block appears to set:

let g = xa('2171042036');   // control
let _ = xa('307909863');    // deviceAttestation
...
dispatchMessage('electron-desktop-features-changed', {
  inAppBrowserUse: d.available,
  computerUse: h.available,
  control: g,
  deviceAttestation: _,
  dil: v,
  multiWindow: y
});
G.info('browser_use_availability_resolved', { ... });

This is the same general Statsig/experimental-feature path that logs the Browser Use result. On the affected machine, every session still logs:

browser_use_availability_resolved available=false browserPane=true platform=Windows reason=statsig-disabled release=26.527.31326

Remote-connections bootstrap never gets past the idle/no-enrollment state:

[remote-connections/window-context] load_completed savedRemoteConnectionCount=0 totalConnectionCount=0
[remote-connections/bootstrap] shared_object_synced connectionCount=0

The evidence points to control gate 2171042036 being off for this device, which hides the Connections UI before enrollment can even start. deviceAttestation gate 307909863 is also in the same server-gated feature block and appears to be part of the remote-control enrollment prerequisites, although I did not directly read a resolved cached boolean for that gate.

Why this still needs a server-side fix

CODEX_ELECTRON_DESKTOP_FEATURE_OVERRIDES could theoretically set control:true, but the app only honors it when buildFlavor === Dev. The signed Store build is Prod/PublicBeta, so that override path is not available for this package.

That leaves no production-safe local override comparable to CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1 for Remote Connections. The remaining routes would involve spoofing feature flags/build flavor/device identity or modifying the signed Store package, which would not be a real user fix and would likely fail server-side enrollment anyway.

Request

Please check/enable the Remote Connections rollout for this account/device, especially the control gate (2171042036) and the related deviceAttestation gate (307909863), or provide the eligibility rule that explains why two machines with the same account, package, and network receive different results.

A diagnostic command or log line that exposes the resolved gate decisions plus the device/install identifier used for bucketing would make this much easier to distinguish from region, account, org-admin, or stale device-state issues.

Additional support cross-reference:

In-app feedback was submitted from the affected machine with ID:

019e36d0-d51c-7011-918d-48dec2cda97c

Attribution: this follow-up was prepared from local diagnostics and posted by Codex on behalf of the user.

New evidence after temporary recovery and Store reinstall

On 2026-05-31, this same Windows host temporarily had the missing surfaces available: the Settings UI showed Connections, the user paired an iPhone to this host, and mobile remote access worked. The phone still shows the affected host as connected.

Later the same day, the user uninstalled Codex and reinstalled it from the Microsoft Store for a clean app install. This reinstall was done specifically to return to a clean app state after earlier local workaround experiments. After that reinstall, the bug returned:

• Settings no longer shows Connections.
• Browser/Chrome surfaces are unavailable again.
• The already-paired iPhone session can still chat with this host/thread.

Current package after reinstall is still:

OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0

Current launch log confirms this is a normal packaged prod build:

2026-05-31T14:42:11.896Z info Launching app ... buildFlavor=prod packaged=true platform=win32

Current logs after reinstall show Remote Control startup calls succeed at the routing layer, but the app has no saved local remote connections and still resolves Browser Use as disabled:

2026-05-31T14:42:13.452Z info [remote-connections/window-context] load_completed savedRemoteConnectionCount=0 totalConnectionCount=0
2026-05-31T14:42:20.630Z info [AppServerConnection] response_routed ... method=remoteControl/enable ... errorCode=null
2026-05-31T14:42:20.748Z info [electron-message-handler] [remote-connections/bootstrap] shared_object_synced connectionCount=0
2026-05-31T14:42:21.832Z info [electron-message-handler] browser_use_availability_resolved available=false browserPane=true platform=Windows reason=statsig-disabled release=26.527.31326

The runtime bundled marketplace after reinstall is again reduced to:

pluginNames=["computer-use","latex"]

because the user-scope CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1 override is still present. Without that override, this would likely be only latex again.

One notable leftover from the temporary good state: the local plugin cache now contains chrome and computer-use, and a chrome native extension host process is running from:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

But the active runtime marketplace does not expose chrome, and the Settings/availability resolver remains statsig-disabled.

This suggests the eligibility state can flip for this same account/device/package, and that a Store reinstall can recreate/reset enough local install/device state to fall back into the disabled rollout bucket, while a previously paired mobile session can continue independently.

I am seeing the same problem on Windows.

Environment:

• OS: Windows
• Codex Windows Store package: OpenAI.Codex 26.527.3686.0
• Install location observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• In-app feedback ID: no-active-thread-019e8255-bbd7-7763-93ae-01ad06bdd1da

Local package evidence:

• The installed package contains these bundled plugins:

• browser
• chrome
• computer-use
• latex

Observed behavior:

• Codex Settings shows Chrome plugin as unavailable.
• Codex Settings shows Computer Use as unavailable.
• Switching to another OpenAI account on the same Windows machine gives the same result.
• Renaming/resetting the old .codex state and signing in again did not make Chrome or Computer Use available.

What this seems to rule out:

• Not a missing local plugin package, because browser/chrome/computer-use are present in the WindowsApps bundled plugin directory.
• Not specific to one OpenAI account, because another account on the same machine shows the same unavailable state.
• Not just a Chrome native host connection problem, because Codex marks the plugin unavailable before reaching normal install/connect flow.

Expected behavior:

• Since the 26.527 Windows package includes browser/chrome/computer-use, Codex should expose Chrome and Computer Use, or show a specific actionable reason for why they are unavailable on this machine.

This appears similar to the reported reason=statsig-disabled / runtime availability gate issue.

no-active-thread-019e8255-bbd7-7763-93ae-01ad06bdd1da

I’m seeing a very similar Windows device-specific Computer Use availability issue, but in my case it fails before the nativePipe/helper layer.

Same ChatGPT Google account can use Computer Use on another Windows PC, but this Windows device has no Computer Use entry in Settings and Plugins search does not find it.

Local evidence:

• %USERPROFILE%\.codex\plugins\cache\openai-primary-runtime contains only documents, spreadsheets, and presentations; no computer-use directory exists in the formal plugin cache.
• %USERPROFILE%\.codex\config.toml has no [plugins."computer-use@openai-primary-runtime"] entry.
• bundled marketplace staging contains empty computer-use directories, but no .codex-plugin/plugin.json.
• %USERPROFILE%\.cache\codex-runtimes\...\node-runtime.tar.xz is 0 bytes.
• Installation id: e7eaf378-2e40-4277-a2f1-1ad97d965289.

So this looks like features.computerUse / computer-use@openai-primary-runtime entitlement or marketplace visibility was not delivered to this installation/device, rather than nativePipe being installed and then failing at runtime.

Adding another Windows/Vietnam data point that matches this issue.

Environment:

OS: Microsoft Windows 11 Pro 10.0.26200, 64-bit
Codex Windows Store package: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
Codex desktop release from logs: 26.601.21317
Timezone: SE Asia Standard Time
Windows HomeLocation: Vietnam
Culture: en-US
Account/workspace UI: Personal settings shown in the app; no local managed config files found

Symptom:

In Codex Settings > Browser, the Browser toggle is disabled with:

Disabled by your organization or unavailable in your region

The feature worked previously on this machine/account, but is now disabled.

Latest desktop logs repeatedly show the same availability gate:

2026-06-04T01:56:34.356Z info [electron-message-handler] browser_use_availability_resolved available=false browserPane=true platform=Windows reason=statsig-disabled release=26.601.21317
2026-06-04T02:05:14.558Z info [electron-message-handler] browser_use_availability_resolved available=false browserPane=true platform=Windows reason=statsig-disabled release=26.601.21317
2026-06-04T03:43:18.812Z info [electron-message-handler] browser_use_availability_resolved available=false browserPane=true platform=Windows reason=statsig-disabled release=26.601.21317

Local package evidence:

The installed Windows Store package contains the bundled plugins:

C:\Program Files\WindowsApps\OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins

browser
chrome
computer-use
latex
sites

But the runtime-written bundled marketplace only exposes latex:

{
  "name": "openai-bundled",
  "interface": {
    "displayName": "OpenAI Bundled"
  },
  "plugins": [
    {
      "name": "latex",
      "source": {
        "source": "local",
        "path": "./plugins/latex"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Research"
    }
  ]
}

Local config / managed policy checks:

%USERPROFILE%\.codex\config.toml has no browser_use, in_app_browser, computer_use, browser@openai-bundled, chrome@openai-bundled, or computer-use@openai-bundled overrides.
%USERPROFILE%\.codex\managed_config.toml: missing
%ProgramData%\OpenAI\Codex\requirements.toml: missing

This looks like the same runtime eligibility / Statsig gate path rather than a missing local plugin package or user config disabling Browser Use.

Request:

Could maintainers check why this installation/account is receiving reason=statsig-disabled for Browser Use on Windows in Vietnam, even though the installed package contains browser, chrome, and computer-use, and no local managed config appears to disable the feature?

Same build here — OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0, Windows 11 Pro (26200),
individual ChatGPT Plus account (organizations: []). I can add a root-cause detail: the
statsig-disabled result is preceded by the Statsig post-login bootstrap throwing, not
evaluating to false.

On every cold launch, the main-process log shows:

error [electron-message-handler] Statsig: error while bootstrapping post-login client
... "path": ["user","custom","workspace_type"], "message": "Invalid input" (invalid_union)

user.custom.workspace_type is null, which fails the client's union schema (accepts
string/number/boolean/array/undefined, but not null). Because bootstrap throws, no gates
are evaluated — owl-feature-bootstrap-cache.json becomes {"enabledOwlFeatureNames":[]} —
and the runtime then collapses the marketplace and removes Chrome:

[BundledPluginsMarketplace] bundled_plugins_marketplace_added marketplaceName=openai-bundled marketplacePluginNames=["browser","latex"]
[BundledPluginsMarketplace] bundled_plugin_uninstall_requested pluginId=chrome@openai-bundled reason=not_in_bundled_marketplace_plugin_names

So on my account, statsig-disabled is a downstream symptom of the bootstrap crashing on a
null workspace_type, not a deliberate region/org decision. Additional notes:

• organizations: [] (personal Plus) — the "disabled by your organization or unavailable in

your region" message is misleading.

• Reproduces identically on two separate Windows 11 PCs on the same account.
• Persists after a full sign-out/sign-in (fresh token, subscription confirmed active), so it's

bound to the server-provided account profile, not local cache.

• workspace_type is not a literal in app.asar, so the null appears to come from the

account profile that gets spread into the Statsig user object.

Suggested fix: coerce null/absent workspace_type to undefined before the Statsig bootstrap
(client-side), and/or correct the account-profile field server-side. Happy to share full logs.

even with node_repl wired back, the native pipe bridge stays untrusted. the runtime trust gate owns browser-use, not the local plugin files.

Follow-up after the app auto-updated to 26.602.4764.0 (still reproduces) — plus a partial workaround and the next bug it exposes.

Workaround (computer-use only): setting the user env var CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1 and fully restarting does flip the gate. The app honors it directly:

platform==='win32' && env.CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE==='1'
  ? {...features, computerUse:true, computerUseNodeRepl:true}
  : features

After restart the bundled marketplace changes from ["browser","latex"] to ["browser","computer-use","latex"] and the native pipe attempts startup — so the gate bypass itself works.

But it dead-ends on a second defect: the computer-use plugin install is skipped, so the helper is never staged where the launcher resolves it:

[BundledPluginsMarketplace] bundled_plugin_install_skipped_missing pluginName=computer-use
[computer-use-native-pipe] ... reason=missing-helper-path status=skipped
[computer-use-native-pipe] computer-use native pipe startup failed
    errorMessage="Windows Computer Use helper paths are unavailable"

The launcher throws unless both paths resolve:

function an({windowsHelperPath:i, windowsHelperTransportModulePath:a}){
  if (i==null || a==null) throw Error("Windows Computer Use helper paths are unavailable");
}
// expects: node_modules/@oai/sky/bin/windows/codex-computer-use.exe
//          node_modules/@oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/helper_transport.js

These resolve from the installed plugin location, which install_skipped_missing never populates — even though the helper exists in the bundled staging copy:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\computer-use\node_modules\@oai\sky\bin\windows\codex-computer-use.exe   (1.6 MB, present)

So on Windows two defects stack:

1. the bundled computer-use plugin's install is skipped, so its helper is never staged to the resolved path (matches the "computer-use runtime missing / 0-byte tarball" reports here);
2. browser-use / Chrome stays gated because the Statsig post-login bootstrap still crashes on user.custom.workspace_type = null (per my earlier comment) → enabledOwlFeatureNames: [] → fallback marketplace.

The env var only bypasses the gate for computer-use; it does not fix the skipped install (1) or the Chrome path (2).

Repro: personal ChatGPT Plus, organizations: [], Windows 11, Codex 26.602.4764.0.

Correction to the "statsig-disabled / region-entitlement gate" framing — across two Windows machines and three app versions, the Chrome drop is driven by hasExternalPluginStateSync, not an eligibility gate. There appear to be two independent defects:

Defect A — what actually drops chrome/computer-use: hasExternalPluginStateSync=false at bundled_plugins_reconcile_started.

| log | app ver | hasExternalPluginStateSync | marketplace written | chrome |
|---|---|---|---|---|
| 06/04 | 26.519.11010 | true | ["browser","chrome","latex"] | installed ✅ |
| 05/30 | 26.519.11010 | false | ["browser","latex"] | excluded ❌ |
| 06/09 | 26.602.9276 | false | ["browser","latex"] | uninstall_requested ❌ |

05/30 is the control: same version as 06/04, no Statsig crash, yet chrome is excluded because sync=false. On my second machine, hasExternalPluginStateSync=false on every launch → chrome never present.

This is not an eligibility/region/trust gate:

• browser_use_availability_resolved = available=true, reason=available in every log;
• no deviceAttestation / entitlement / statsig-disabled lines anywhere;
• the experimental/Statsig feature set (Features enabled enabledFeatures=…) never contains chrome.

So chrome tracks a racy external-plugin-state-sync that's intermittently false — version-independent, reproducing on two machines.

Defect B — separate, new in 26.602: post-login Statsig bootstrap crashes on user.custom.workspace_type = null.

{ "code":"invalid_union", "path":["user","custom","workspace_type"],
  "errors":[["string"],["number"],["boolean"],["array"],["undefined"]] }

Fails all five branches including undefined → the field is present-and-null (personal account, org title "Personal", no workspace). Union omits null; fix = .nullable() / coerce null→undefined. No such crash in any 26.519 log. Fires ~32 s after the chrome decision, so it does not cause the drop — it does leave owl-feature-bootstrap-cache.json = {"enabledOwlFeatureNames":[]}.

Net: the Chrome/Computer-Use unavailability is Defect A (hasExternalPluginStateSync=false), not a region/entitlement gate, and would not be fixed by correcting workspace_type alone. Repro: personal Plus, organizations:[{title:"Personal",role:"owner"}], two Windows 11 PCs, 26.519.11010 → 26.602.9276.

Update — this is intermittent on both of my machines, which pins it as a startup ordering race rather than any per-account or per-device state.

Same ChatGPT Plus account, two Windows 11 machines, both on 26.608.1337.0. Chrome + computer-use availability flaps between launches on each machine, tracking hasExternalPluginStateSync at bundled_plugins_reconcile_started:

• sync=true launch → marketplace ["browser","chrome","computer-use","latex"], chrome_extension_sync_decision=keep_installed, the cua runtime installs and codex-computer-use.exe + native pipe go live → Chrome + Computer Use work.
• sync=false launch → marketplace ["browser","latex"], any installed chrome is reaped (not_in_bundled_marketplace_plugin_names), and bundled_plugin_install_skipped_missing pluginName=computer-use (cua runtime never downloads) → both features disappear.

Machine A had one sync=true launch and worked, then later launches went sync=false and it broke again. Machine B has been sync=false across 6+ relaunches. So it isn't a "good machine vs bad machine" — each machine is non-deterministic across launches.

Every false launch logs, just before the reconcile:

refresh_local_remote_control_client_id_failed "Sign in to ChatGPT … to check remote control authorization."
bundled_plugins_reconcile_started hasExternalPluginStateSync=false reason=startup

…and a full sign-out/sign-in does not help — that warning fires even immediately after signing in. This strongly suggests the bundled-plugin reconcile races ahead of account/remote-control state readiness and reads sync as false when it's simply not ready yet, then reaps installed plugins.

Suggested fix: have the startup reconcile await external-plugin-state-sync readiness (or re-reconcile once it resolves) before writing the bundled marketplace, instead of treating not-yet-ready as false. Repro: personal Plus, organizations:[{title:"Personal",role:"owner"}], 2× Windows 11, 26.608.1337.0.