[Bug]: Codex provider can't use the Chrome plugin since 26.1023.50603: browser-access env not passed to codex app-server

[dmartss]

What happens

Since the Codex Chrome plugin auto-updated to 26.1023.50603, every browser call from a T3-hosted Codex session fails with "The browser access host is unavailable". The same browser work from the ChatGPT/Codex desktop app still works, and T3-hosted Codex sessions could use Chrome on the previous plugin version earlier the same day.

Why (what we observed)

• The plugin's browser service now expects BROWSER_USE_ACCESS_PIPE_PATH, BROWSER_USE_ACCESS_VERIFYING_IDENTITY and BROWSER_USE_ACCESS_EXECUTOR_ID in the app-server environment.
• The ChatGPT app's own codex app-server processes carry them (we checked variable names only, not values).
• T3's (t3 serve → codex app-server, 0.1.4-nightly.20261027.3783, macOS) carries none, and the Codex provider settings have no env passthrough.

Ask

Supported browser-access wiring for the Codex provider (obtaining the access pipe and identity the way the ChatGPT app does), or an env passthrough on the provider instance. We didn't copy the identity variable ourselves, since it looks like an access control.

Impact

All T3-hosted Codex browser automations are blocked until then. Possibly related to the closed #19924 (a different cause, the same symptom: works in the Codex app, fails under T3).

[sitenzo]

Related upstream Codex issue: openai/codex#57641

We reproduced the same error on Windows in T3 Code Desktop/server 0.1.4-nightly.20261028.3824 with bundled unified-computer-use plugin 26.1023.50603: native application discovery works, but browser discovery returns an empty list and The browser access host is unavailable. Direct Edge browser acquisition fails with the same error.

The upstream report also reproduces this outside T3, in the standalone Codex CLI. We added the T3-hosted reproduction and requested clarification of the supported browser-access bootstrap for third-party codex app-server hosts here: openai/codex#57641 (comment)

This does not establish that T3 drops the browser-access environment variables or that forwarding variables alone would restore authorized access. No configuration, plugin files, or authorization checks were changed.

Investigated with Codex, model gpt-6.1-sol, via T3 triage.