[Windows] Previously working Chrome control disappears; disabled organization/region message prevents task recovery

What version of the Codex App are you using (From "About Codex" dialog)?

Windows installed package version: 26.908.4834.0, verified through Get-AppxPackage OpenAI.Codex, not copied from the About dialog. The installed bundled Chrome/Computer Use resources are version 26.908.40834.

What subscription do you have?

ChatGPT Pro, verified with the desktop app's read-only usage information. The exact account/workspace eligibility evaluation has not been established.

What platform is your computer?

Windows x64: Microsoft Windows NT 10.0.26200.0. The affected local task runs with native Windows paths and PowerShell. No controlled Windows-versus-WSL backend comparison has been performed.

What issue are you seeing?

Chrome browser control previously worked in a long-running local Codex production task, including reading a signed-in external video-production site and submitting earlier video tests. Later, the previously working browser-control callable was no longer exposed to the task. Production could not continue.

Current user-visible state:

• Entering a half-width @ opens the mention menu, but Chrome does not appear. The user supplied screenshots covering the menu from top to bottom.

• Settings > Computer use > Google Chrome is disabled with an unavailable toggle and the exact message:

  Disabled by your organization or unavailable in your region

• Current task tool discovery does not expose the previously working cua_repl browser-control callable.

The settings screenshot is the clearest current evidence. The combined organization/region message does not establish which condition actually applies, whether availability was legitimately changed, or whether the app has an incorrect/stale feature evaluation.

What steps can reproduce the bug?

This is an observed transition, not a reliably reproduced trigger:

1. Use Chrome browser control successfully in an existing Windows Codex task.
2. Continue the same local project, including realtime voice and ordinary text turns.
3. Observe that subsequent tool discovery no longer exposes browser control.
4. Enter @ in the task composer: Chrome is absent.
5. Open Settings > Computer use: Chrome has the disabled organization/region message and cannot be selected.

The earlier successful browser observations were around 2026-09-17 01:54 JST; current UI screenshots were supplied around 03:14-03:24 JST. These are observation times, not a proven onset time. A transition from voice to ordinary text occurred in the surrounding workflow, but voice termination has not been proven to cause the loss.

What is the expected behavior?

• If Chrome remains eligible, previously working browser control should remain usable or recover through the supported task connection flow.
• If it is genuinely ineligible, show a specific actionable reason: workspace policy, regional eligibility, unsupported backend, feature rollout, or a failed availability evaluation.
• Avoid presenting an ambiguous organization/region message for an unrelated client initialization problem.
• Keep task tool exposure, the mention menu, and settings availability consistent.

Please investigate the actual availability reason and whether there is a supported fix for this previously working Windows installation. We are not requesting a policy bypass.

Additional information

Read-only local checks found:

• Chrome and the Codex extension-host.exe process were still running.
• The bundled extension diagnostic reported the expected Chrome extension installed/enabled in the selected Default browser profile. Process presence and extension installation do not prove a live task connection or the identity of the current signed-in site account.
• A bounded native Computer Use app-list check earlier failed with failed to connect native pipe: ... (os error 2) / file not found. The configured computer-use endpoint was absent from a read-only Windows named-pipe enumeration, while browser-use endpoints existed. This is a separate diagnostic observation, not proof of the Chrome eligibility root cause.
• The configured trusted browser service referred to an absent legacy browser plugin directory, while current bundled resources are under chrome. Its role in this failure is unproven.
• A bundled native-host-manifest diagnostic reported missing expected registry/manifest entries despite the running extension host. This inconsistency is not sufficient to infer that reinstalling will fix the task.

No permissions were weakened, no alternate control route was used after the disabled-feature screenshot, and no VPN, account switching, reinstall, app restart, or new paid generation was performed during the current recovery investigation.

Related reports reviewed before submission:

• #45286: same disabled message on a similar Windows desktop release, without this prior-working task transition.
• #26735: same message with a reported statsig-disabled evaluation on a different release/account. We have not established that evaluation in this case.
• #44253: explicitly reproduced wsl-disabled case. We have not established that cause here.
• #45281: our earlier cross-task-tool disappearance report, submitted separately. A shared mechanism is not established.

The current report adds a prior-working Chrome/task regression with observed mismatch between existing local integration components and unavailable app/task controls. No raw logs, session transcript, account identifiers, credentials, personal file paths, or unredacted desktop screenshots are included.

Begin at Settings > Computer use > Google Chrome and compare its disabled state with task tool discovery and the @ mention menu; inspect the native pipe and extension-host diagnostics described in the report. Done means identifying the eligibility or initialization cause and providing a supported recovery or specific actionable reason, with these surfaces consistent.