What issue are you seeing?
On Windows, the Codex Chrome plugin works in an interactive Codex Desktop thread, but the same project automation running as a scheduled cron job does not receive any Chrome/browser automation tools.
The automation is configured to use Chrome explicitly, but when the scheduled run starts it reports that the Chrome skill/plugin is not available in that Codex run and that there are no callable Chrome tools. No tab can be opened, no DOM snapshot can be taken, and no Chrome cleanup/finalize call can run.
This looks like a difference between the interactive Codex runtime and the isolated cron automation runtime.
Environment
- OS: Windows 11
- Codex Desktop: version unknown from this report
- Chrome plugin: enabled in
~/.codex/config.toml
- Chrome extension: working in an interactive Codex session
- Automation kind:
cron
- Automation execution_environment:
local
Relevant local config shows:
[plugins."chrome@openai-bundled"]
enabled = true
The scheduled automation TOML includes:
kind = "cron"
execution_environment = "local"
Reproduction
- Enable and verify the Codex Chrome plugin in Codex Desktop on Windows.
- In an interactive Codex thread, use Chrome successfully for a browser workflow.
- Create a scheduled cron automation in the same Codex project whose prompt explicitly requires Chrome /
@chrome / Codex Chrome Extension.
- Let the automation run, or trigger it manually as an automation run.
- Observe that the automation runtime does not expose Chrome/browser tools.
Actual result
The automation reports:
Chrome skill/plugin is not available in this Codex run (no callable Chrome tools), so the flow cannot start.
No tab open / DOM snapshot / retries / finalize.
Additional retries produced the same result:
Chrome skill still not available in this session (no callable Chrome tools), so flow cannot run.
Expected result
If the Chrome plugin is enabled and works in the interactive Codex Desktop session, a local cron automation that explicitly asks to use Chrome should either:
- expose the same Chrome browser automation backend to the automation runtime, or
- clearly document that scheduled cron automations cannot use the Chrome extension backend, or
- provide an automation setting for enabling/disabling browser plugins per automation.
Why this matters
Some repeatable workflows require an authenticated, real Chrome profile instead of the in-app browser. In this case, the in-app browser was unreliable for a travel booking flow, while Chrome worked interactively. The workflow cannot be automated reliably unless Chrome is available to scheduled automation runs.
Related issues
This appears related to other reports where Chrome is connected in UI but unavailable or unreliable in the runtime, such as #21916, #21900, #22079, and #21876.
Additional notes
No secrets or private credentials are included here. The workflow itself involved a browser task plus a Google Sheets write, but the failure happens before any page opens: the automation runtime simply does not expose Chrome tools.
What issue are you seeing?
On Windows, the Codex Chrome plugin works in an interactive Codex Desktop thread, but the same project automation running as a scheduled cron job does not receive any Chrome/browser automation tools.
The automation is configured to use Chrome explicitly, but when the scheduled run starts it reports that the Chrome skill/plugin is not available in that Codex run and that there are no callable Chrome tools. No tab can be opened, no DOM snapshot can be taken, and no Chrome cleanup/finalize call can run.
This looks like a difference between the interactive Codex runtime and the isolated cron automation runtime.
Environment
~/.codex/config.tomlcronlocalRelevant local config shows:
The scheduled automation TOML includes:
Reproduction
@chrome/ Codex Chrome Extension.Actual result
The automation reports:
Additional retries produced the same result:
Expected result
If the Chrome plugin is enabled and works in the interactive Codex Desktop session, a local cron automation that explicitly asks to use Chrome should either:
Why this matters
Some repeatable workflows require an authenticated, real Chrome profile instead of the in-app browser. In this case, the in-app browser was unreliable for a travel booking flow, while Chrome worked interactively. The workflow cannot be automated reliably unless Chrome is available to scheduled automation runs.
Related issues
This appears related to other reports where Chrome is connected in UI but unavailable or unreliable in the runtime, such as #21916, #21900, #22079, and #21876.
Additional notes
No secrets or private credentials are included here. The workflow itself involved a browser task plus a Google Sheets write, but the failure happens before any page opens: the automation runtime simply does not expose Chrome tools.