[Windows][Chrome] Extension backend connects but existing user tabs are empty; recovery after update + disabling .agent-browser autostart

Summary

On Windows Codex Desktop, the Chrome extension backend initialized successfully, but existing manually opened Chrome tabs were not discoverable.

The Chrome side appeared healthy:

• Chrome was running in the Default profile.
• The ChatGPT/Codex Chrome extension was installed and enabled.
• Extension version: 1.2.27268.51612.
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg.
• Native application communication permission was present.
• Codex Settings → Computer Use showed Chrome as installed/managed.
• The native host registration and extension-host.exe were present.

Codex could initialize a Chrome backend of type extension, and it could create an agent-controlled tab, but manually opened user tabs remained invisible. In one test, even the previously created agent tab later disappeared from the tab inventory.

A successful recovery occurred after:

1. Updating the Windows AppX package from 26.820.10647.0 to 26.825.4187.0 through Microsoft Store.
2. Discovering that Codex's private .agent-browser Chrome was launching automatically at Windows login through a GoogleChromeAutoLaunch_* registry value.
3. Backing up and removing only that startup value.
4. Terminating only the Chrome processes running from %USERPROFILE%\.agent-browser\....
5. Starting a fresh Codex task and reinitializing the Chrome extension backend.

After that, Codex immediately enumerated existing manually opened Chrome tabs, could claim one, inspect/interact with it, and complete the intended browser workflow.

I cannot determine whether the recovery came solely from the Codex update, clearing the stale .agent-browser startup state, or the combination. The .agent-browser autostart behavior may nevertheless be a useful diagnostic lead for affected Windows users.

Environment before recovery

OS: Windows
Codex AppX package: 26.820.10647.0
Chrome extension: 1.2.27268.51612
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Chrome profile: Default
Full CDP access: enabled during testing

After Microsoft Store update:

Codex AppX package: 26.825.4187.0

Initial symptom

A fresh Codex task could initialize the Chrome backend:

Chrome backend: Chrome
Type: extension
Open user tabs: none

The extension backend itself was therefore available, but existing user-tab discovery was empty.

Isolation tests

1. Chrome profile check

chrome://version showed the active profile path ending in:

...\Google\Chrome\User Data\Default

So this was not a profile mismatch.

2. Extension check

The Chrome extension was enabled and had the expected ID and native-app permission:

Version: 1.2.27268.51612
ID: hehggadaopoacecdllhhajmbjkdcmajg

3. Agent-created tab test

Codex was asked to create https://example.com using the existing Chrome extension backend.

Result:

Opened successfully: yes
Agent-controlled tabs:
- Example Domain — https://example.com/
Existing user tabs: none

This showed that browser control itself worked while existing-user-tab enumeration did not.

4. Manual-tab test

A new normal Chrome tab was manually opened after the extension backend had initialized. Codex was then asked to refresh browser.user.openTabs().

Result:

User tabs: none
Agent-controlled tabs: none

The previously created agent tab had also disappeared from the reported inventory, suggesting stale/unstable browser session state rather than a simple Chrome permission failure.

Important Windows startup finding

After a full Windows reboot, before manually opening Codex, processes from Codex's private browser runtime were already running:

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

The root .agent-browser Chrome process had:

ParentName: explorer.exe
CommandLine: "...\.agent-browser\browsers\chrome-148.0.7778.167\chrome.exe" --no-startup-window /prefetch:5

Registry inspection then found:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

with a value named similar to:

GoogleChromeAutoLaunch_<hex>

whose value pointed directly to:

"%USERPROFILE%\.agent-browser\browsers\chrome-148.0.7778.167\chrome.exe" --no-startup-window /prefetch:5

This meant the Codex private agent-browser Chrome was being silently launched at Windows login, independently of the fresh Chrome-extension task being tested.

Recovery procedure used

A. Update Codex

Updated Microsoft Store/AppX package:

26.820.10647.0
→
26.825.4187.0

B. Back up and remove only the .agent-browser autostart value

The GoogleChromeAutoLaunch_* value pointing to .agent-browser was saved to a text backup and then removed from:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

No unrelated startup values were changed.

C. Stop only the private agent-browser Chrome processes

Only chrome.exe processes whose executable path was under:

%USERPROFILE%\.agent-browser\

were terminated. Normal Google Chrome was left untouched.

After cleanup:

SUCCESS: No Codex agent-browser Chrome processes remain.

D. Fresh Codex task

A new Codex task initialized the Chrome extension backend and listed existing user tabs.

Result:

Chrome extension backend initialized.
Type: extension
Existing user tabs:
1. <normal manually opened tab>
2. <normal manually opened tab>

Codex then successfully:

• claimed an existing user tab,
• read its current title/URL,
• inspected and interacted with the page,
• and completed a multi-step browser workflow against that pre-existing tab.

Before / after

Before recovery:

Chrome backend: extension
Existing user tabs: none

and later:

User tabs: none
Agent-controlled tabs: none

even though an agent-created tab had existed.

After recovery:

Chrome backend: extension
Existing user tabs: correctly enumerated
Existing tab claim: success
Page inspection/interaction: success

Suggested diagnostic for other Windows reports

For Windows users where:

• Chrome is running,
• the extension/native host looks healthy,
• the extension backend initializes,
• but browser.user.openTabs() is empty or tab inventory becomes unstable,

it may be useful to check whether Codex's private browser has registered itself for Windows startup:

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'

Look specifically for a GoogleChromeAutoLaunch_* value whose executable path is under:

%USERPROFILE%\.agent-browser\browsers\...

If present, I would recommend treating it as a diagnostic lead rather than blindly deleting it: back it up first, confirm it points to .agent-browser, temporarily disable/remove only that value, stop only the corresponding .agent-browser Chrome processes, start a fresh Codex task, and retest tab discovery.

Caveat

This is a confirmed recovery case, not proof of a universal root cause.

Two meaningful variables changed before the final successful test:

1. Codex was updated from 26.820.10647.0 to 26.825.4187.0.
2. The stale/automatic .agent-browser startup state was removed and its running processes were stopped.

A maintainer may be able to determine from code/telemetry whether .agent-browser Chrome registering itself as GoogleChromeAutoLaunch_* is intended behavior and whether that can interfere with Chrome-extension browser-session discovery.

Related issues

• #27865 — Windows Store Codex: Chrome backend not registered / empty browser list despite healthy extension/native host.
• #40352 — Windows Chrome stale-session behavior where tab discovery/control becomes inconsistent.
• #41246 — Windows browser tab registration state instability where visible tabs disappear from the control-layer inventory.

Suggested product improvements

• Expose a diagnostic that distinguishes:
  • extension connected,
  • native host connected,
  • extension backend registered,
  • user tabs enumerated,
  • tab claimed,
  • page interaction available.
• If a private .agent-browser Chrome instance is auto-launched at Windows login, make its purpose/status visible in diagnostics.
• Detect and repair stale browser-session ownership automatically instead of returning an empty tab inventory.
• Provide a supported reset/recovery action that clears only browser-control state without requiring users to reinstall Chrome or the extension.

Start by tracing the browser.user.openTabs() path and the Windows startup handling described in the report, especially the GoogleChromeAutoLaunch_* value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Compare related issues #27865, #40352, and #41246 to determine whether the .agent-browser process affects extension-session discovery. Done means identifying the cause or documenting the recovery behavior and adding a reliable diagnostic or reset path.