🩹 Bundled Browser/Chrome/Computer Use plugins disappear after Windows app updates due to stale bundled marketplace path

Bundled Browser/Chrome/Computer Use plugins disappear after Windows app updates due to stale bundled marketplace path

Environment

Codex Desktop version: <paste current app version>
Windows version / build: <paste Windows version and OS build>
Install type: Microsoft Store / WindowsApps packaged app
Affected bundled plugins/skills:
- Browser
- Chrome
- Computer Use

Summary

After some Codex Desktop updates on Windows, bundled plugins/skills become unavailable until local repair. This has happened repeatedly across multiple app updates.

The recurring pattern is that Codex updates into a new versioned WindowsApps directory, but the local Codex config continues to point the bundled marketplace source at an older versioned app directory. After that, the bundled marketplace temp/cache state becomes incomplete, commonly leaving only the chrome plugin available while browser and computer-use disappear.

This appears to be an app update / marketplace registration regression, not a confirmed security issue.

Expected Behavior

After Codex Desktop updates, bundled plugins should remain registered and available.

Specifically:

[marketplaces.openai-bundled].source should point to the current app version's bundled marketplace source.
The bundled marketplace temp/cache should be refreshed from the current app source.
Bundled plugins browser, chrome, and computer-use should remain available after restart/update.

Actual Behavior

After an update:

Bundled plugins/skills disappear or become unavailable.
Local config may still reference an older versioned WindowsApps app path.
The bundled marketplace temp/cache can become incomplete.
In observed cases, .tmp/bundled-marketplaces/openai-bundled/plugins commonly contained only chrome.
The current app's bundled source manifests still existed and parsed correctly for browser, chrome, and computer-use.
Repairing the marketplace source path and rebuilding/restoring temp/cache from the current bundled source restored all three plugins.

Reproduction Pattern

This is intermittent but has recurred after multiple Windows app updates.

Install / run Codex Desktop on Windows.
Confirm bundled plugins are available.
Let Codex Desktop update to a newer packaged app version.
Restart Codex.
Check bundled plugin availability.
Inspect local bundled marketplace config/state:
- %USERPROFILE%\.codex\config.toml
- %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins
- Codex cache directories, if relevant
Observe whether [marketplaces.openai-bundled].source still points to an older OpenAI.Codex_<version> directory instead of the currently running app directory.

Evidence / Diagnostics

Most recent observed instance:

Running app package: OpenAI.Codex_26.623.4041.0
Stale configured bundled source before repair: OpenAI.Codex_26.616.10790.0
Current bundled source plugin manifest versions: 26.623.31921
Initial temp bundled marketplace plugins directory contained only:
- chrome
Current bundled source under the active app root still contained valid manifests for:
- browser
- chrome
- computer-use
After correcting the bundled marketplace source and restoring/rebuilding temp/cache from the current app source, all three plugins validated and became available again.

Prior local occurrences involved these app package versions:

OpenAI.Codex_26.616.6631.0
OpenAI.Codex_26.616.9593.0
OpenAI.Codex_26.616.10790.0
OpenAI.Codex_26.623.4041.0

Suggested diagnostics to attach:

# Redacted excerpt from %USERPROFILE%\.codex\config.toml
[marketplaces.openai-bundled]
source = "<redacted path showing old OpenAI.Codex_<version> vs current OpenAI.Codex_<version>>"

# Redacted directory listing
%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins
<show which plugin folders are present>

# Current app bundled source listing
<redacted WindowsApps path>\OpenAI.Codex_<current version>\...
<show browser/chrome/computer-use manifests exist and parse>

Workaround

A local repair restores functionality:

Update [marketplaces.openai-bundled].source in %USERPROFILE%\.codex\config.toml to point at the current OpenAI.Codex_<version> bundled marketplace source.
Restore/rebuild the bundled marketplace temp/cache from the current app source.
Restart Codex.
Validate that browser, chrome, and computer-use are available again.

Requested Fix

Please make Codex Desktop resilient to Windows packaged app updates by ensuring the bundled marketplace registration is refreshed when the app version/path changes.

Possible fixes:

Avoid persisting an absolute versioned WindowsApps path for the bundled marketplace source.
On startup, detect when [marketplaces.openai-bundled].source points to an older/non-current app package path.
Re-register or migrate the bundled marketplace source to the current app root automatically.
Rebuild bundled marketplace temp/cache atomically when the bundled source version changes.
Validate that all expected bundled plugins are present after update and repair automatically if not.

Privacy / Security Note

This report intentionally excludes private documents, credentials, full local state dumps, and old conversation text. Based on current evidence, this appears to be an update/registration regression affecting bundled plugin availability, not a confirmed security vulnerability.

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

Browser / Google Chrome plugins are removed on Codex startup after successful UI Install #28703
I cannot find the "Chrome" and "Browser" plugins in the plugin list. #30259

Powered by Codex Action

I reviewed the suggested duplicates.

This looks related to #28703 and possibly the same Windows bundled-plugin reconciliation/update family of bugs, but I am keeping this issue open for now because it adds a more specific update-path diagnostic:

after Codex updates, [marketplaces.openai-bundled].source can remain pointed at an older versioned OpenAI.Codex_<version> WindowsApps path;
.tmp\bundled-marketplaces\openai-bundled\plugins can become incomplete;
the current app package still contains valid browser, chrome, and computer-use bundled source manifests;
updating the source path and rebuilding/restoring bundled marketplace temp/cache restores the plugins.

#30259 appears related but is already closed and was less specific about the stale bundled marketplace source path.

I pushed a candidate fix to my fork for this stale bundled-marketplace update path.

Compare: main...Nicolas0315:codex:codex/bundled-marketplace-source-refresh
Commit: Nicolas0315/codex@7c0e9d7

What changed:

openai-bundled / openai-bundled-alpha configured roots now keep using the configured source when it still has a manifest, but fall back to the managed .tmp/bundled-marketplaces/<name> cache when the persisted local source no longer has a marketplace manifest.
codex plugin marketplace add can refresh a changed local source for those reserved bundled marketplace names, so an app package path change is not treated like an ordinary conflicting marketplace.
Ordinary custom marketplaces still reject same-name/different-source local refreshes.

Validation:

Local: just fmt, git diff --check, focused codex-core-plugins regression tests 4/4, focused codex-cli snapshot tests 3/3.
Local full just test -p codex-core-plugins: 296 passed, 1 failed in manager::tests::skills_service_reuses_skills_parsed_during_plugin_load; that failure reproduces standalone here and is due ambient Azure/Lottie skills leaking into this machine's test environment, unrelated to marketplace source handling.
SSH exact-commit validation:
- cyberagent-mac-m5max: git diff --check HEAD~1 HEAD, focused core tests 4/4, focused CLI tests 3/3 passed.
- nicolas-macbook-pro: git diff --check HEAD~1 HEAD passed; Rust toolchain unavailable on that host.
- nicolas2025: git diff --check HEAD~1 HEAD, focused cargo test -p codex-core-plugins cases 4/4, focused cargo test -p codex-cli cases 3/3 passed.
- rtx5060ti: git diff --check HEAD~1 HEAD passed; Rust compile tests skipped because this host still has the known linker configuration issue that rejects MSVC linker flags.

Boundary: this covers the core side of stale persisted source recovery and source refresh. If Desktop fails to repopulate .tmp/bundled-marketplaces/openai-bundled at all, that packaging/startup copy path still needs to be fixed separately.

Thanks, this looks aligned with the stale persisted source evidence from my repro.

The source-refresh behavior you described should cover the concrete case I reported where [marketplaces.openai-bundled].source remained pointed at an older OpenAI.Codex_<version> WindowsApps path even though the current app package still had valid bundled manifests.

One extra data point from my local repro: after updates, .tmp\bundled-marketplaces\openai-bundled\plugins was sometimes incomplete as well, commonly retaining only chrome. In that state, repairing only the persisted source path was not always sufficient; I also had to restore/rebuild the bundled marketplace temp/cache from the current app source.

So I agree with your boundary note: this candidate fix seems to address the core stale-source/source-refresh side, while a separate Desktop packaging/startup copy path may still need attention if .tmp/bundled-marketplaces/openai-bundled is not repopulated correctly.

Adding another Windows Store update repro from Codex Desktop 26.623.5546.0.

Observed sequence:

Previous repaired/working app package source: OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0.
After updating Codex Desktop, current installed package became: OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0.
%USERPROFILE%\.codex\config.toml still had [marketplaces.openai-bundled].source pointing at the old OpenAI.Codex_26.623.4041.0...\app\resources\plugins\openai-bundled path.
The old 26.623.4041.0 WindowsApps path no longer existed; the new 26.623.5546.0 bundled source existed and contained valid bundled plugins.
Before repair, codex plugin list failed with:

Error: failed to load configured marketplace snapshot(s):
- `openai-bundled` at \\?\C:\Program Files\WindowsApps\OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled: marketplace root does not contain a supported manifest

Additional cache/link state from this repro:

Current app bundled source manifests for browser, chrome, and computer-use were version 26.623.42026.
Existing local cache still had older bundled plugin version 26.623.31921.
browser/latest still pointed at ...\browser\26.623.31921.
chrome/latest still pointed at %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome.
computer-use/latest eventually pointed at ...\computer-use\26.623.42026 after re-adding the plugin.

Manual repair that restored the plugins:

codex plugin marketplace remove openai-bundled
codex plugin marketplace add "C:\Program Files\WindowsApps\OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled"
codex plugin add browser@openai-bundled
codex plugin add chrome@openai-bundled
codex plugin add computer-use@openai-bundled

PowerShell Remove-Item hit a null-reference error on some stale latest junctions, so I recreated the latest junctions with a narrower link-only delete via [System.IO.Directory]::Delete($latest, $false) followed by New-Item -ItemType Junction.

Post-repair validation:

browser@openai-bundled       installed, enabled  26.623.42026
chrome@openai-bundled        installed, enabled  26.623.42026
computer-use@openai-bundled  installed, enabled  26.623.42026

codex doctor --summary reported 0 fail, and Browser runtime discovery could see both Chrome and Codex In-app Browser.

This confirms the stale versioned WindowsApps marketplace source is still reproducible after a later update. It also adds one extra detail for the fix boundary: startup/update repair may need to validate not only [marketplaces.openai-bundled].source, but also the plugin cache latest junctions, because they can remain pointed at old cache versions or at the transient .tmp\bundled-marketplaces source after the marketplace source is repaired.

I prepared a candidate fix branch for this issue here:

The patch lets managed bundled marketplaces refresh their stale local source path after Windows package updates, and falls back to .tmp/bundled-marketplaces/<name> when a configured bundled local source no longer has a marketplace manifest.

Validation:

cargo test -p codex-core-plugins marketplace_add
cargo test -p codex-core-plugins list_marketplaces
git diff --check

I attempted to open a draft PR from the fork, but the current GitHub token/integration is not permitted to create a PR against openai/codex (Resource not accessible by integration).

Thanks for the additional Windows Store update repro. This matches the stale bundled marketplace source failure mode I reported, and the extra latest junction detail is useful.

I confirmed locally that this is not just a stale [marketplaces.openai-bundled].source problem. After repair, bundled plugin cache links can also remain stale or point back into .tmp/bundled-marketplaces/openai-bundled/plugins/<plugin>, so startup/update recovery should validate and refresh the per-plugin latest link as well as the marketplace source/cache contents.

For the candidate fix: I agree a maintainer-side cherry-pick or a normal manual fork PR would be the right path. The integration-token PR failure looks like a GitHub permission limitation rather than evidence that the patch is not useful.

I prepared a fork branch with a regression-tested fix for this issue, but GitHub returns a CreatePullRequest permission error for this account when targeting openai/codex directly.

Branch: https://github.com/xiaokangzaina/codex/tree/codex/refresh-stale-bundled-marketplace
Compare: https://github.com/openai/codex/compare/main...xiaokangzaina:codex/refresh-stale-bundled-marketplace?expand=1
Commit: xiaokangzaina@92f70c0

Summary:

allow managed openai-bundled marketplaces to refresh from a new local directory source instead of rejecting the same marketplace name after Windows app updates
fall back to the managed bundled marketplace root when the configured bundled local source points at a stale/missing path
add regression tests for both stale-source paths

Validation:

cargo test -p codex-core-plugins marketplace_add::tests::add_marketplace_sync_refreshes_bundled_local_directory_source -- --exact
cargo test -p codex-core-plugins manager::tests::list_marketplaces_falls_back_to_managed_bundled_root_when_configured_source_is_stale -- --exact
git diff --check upstream/main...HEAD

Still reproducible after multiple later Windows Store / Desktop updates.

Latest observed repro on Windows Codex Desktop:

Current running app package: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0
Stale [marketplaces.openai-bundled].source before repair still pointed at: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled
Current app bundled source exists and contains valid manifests for:
- browser
- computer-use
Current bundled plugin manifest version: 26.623.141536
BROWSER_USE_CODEX_APP_VERSION in config also showed 26.623.141536, so the plugin metadata/runtime version matched the current app package, but the persisted marketplace source was still one package behind.
Manual repair was again only to update [marketplaces.openai-bundled].source to the current package's ...\app\resources\plugins\openai-bundled, then restart Codex.
node_repl remained healthy (nodeRepl.write('ok') returned ok), so this latest repro was not a node runtime failure.

Recent consecutive local pattern from this machine:

Current 26.623.4041.0, stale source 26.616.10790.0
Current 26.623.5546.0, stale source 26.623.4041.0
Current 26.623.9142.0, stale source 26.623.5546.0
Current 26.623.11225.0, stale source 26.623.9142.0
Current 26.623.13972.0, stale source 26.623.11225.0
Current 26.623.19656.0, stale source 26.623.13972.0

So this is no longer intermittent on this Windows Store install: after each app update, the persisted openai-bundled source remains pointed at the previous versioned WindowsApps package path. The workaround is simple, but it has to be repeated after every update, which effectively leaves Browser / Computer Use unavailable until manual config repair.

Requested fix remains the same: on startup/update, reconcile [marketplaces.openai-bundled].source against the currently running WindowsApps package, or avoid persisting a versioned WindowsApps package path in user config for bundled marketplaces.

Same issue; Feedback ID: 019f5dac-6042-7652-b369-7a6d9e8da34d

Adding a newer update/recovery instance with the exact source-conflict and uninstall errors.

Environment

Windows 11 x64
Microsoft Store package: OpenAI.Codex_26.707.12708.0
Old bundled plugin/cache version still present: 26.707.61608
New bundled marketplace/plugin version generated by the update: 26.707.91948
The Store package was already on drive C: for this update

Confirmed update conflict

A legacy openai-bundled marketplace entry remained in %USERPROFILE%\.codex\config.toml from an earlier manual recovery:

[marketplaces.openai-bundled]
last_updated = "2026-07-09T07:54:16Z"
source_type = "local"
source = '\\?\C:\Users\<user>\.codex\plugins\cache\openai-bundled'

The updated app generated the new managed marketplace at:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled

but startup reconciliation failed with:

marketplace 'openai-bundled' is already added from a different source;
remove it before adding this source

This left old and new bundled-plugin state mixed. The settings UI then showed the in-app Browser as unavailable and omitted Computer Use even though the native backends/pipes could still be present.

Chrome uninstall failure

Three UI uninstall attempts failed with the same log error:

failed to uninstall plugin:
failed to remove existing plugin cache entry:
Access is denied. (os error 5)
pluginId=chrome@openai-bundled

An orphaned Node REPL process was also present: its recorded parent PID no longer existed. This may have held a cache handle, but I did not prove which process owned the denied handle. The error is in the same Windows cache-lock family as #22114, while the reserved-marketplace source collision is independently confirmed by the log above.

Recovery performed

Backed up config.toml.
Removed only the four-line legacy [marketplaces.openai-bundled] block.
Preserved the existing enabled entries for computer-use@openai-bundled and chrome@openai-bundled.
Verified that the orphan Node process's parent no longer existed, then terminated only that orphan.
Did not manually edit/delete the native-host manifest, registry keys, or plugin cache.
Fully exited and restarted Codex.
Confirmed that the app automatically registered openai-bundled from the managed .tmp\bundled-marketplaces path.
Retried through the plugin UI.

After restart, Browser installation, Chrome uninstall, and Chrome reinstall all succeeded. Browser, Computer Use, and Chrome caches were rebuilt at 26.707.91948. The official Computer Use bootstrap returned connected: true, and the Chrome extension backend connected successfully after Chrome was launched.

Requested behavior

For the reserved bundled marketplace names, an app update should migrate or replace a legacy source registration automatically, or at minimum surface an actionable conflict instead of leaving mixed cache/UI state. Plugin refresh/uninstall should also avoid deleting a cache tree while a bundled runtime/native host/Node worker may still hold it, and should fail without partially materializing the replacement.

This recovery did not fix the separate in-app Browser crash after real-page navigation.

Disclosure: I’m the maintainer of WinBridge Recovery, an independent, non-commercial Windows recovery utility for Codex Desktop.

I built it around essentially this same class of post-update state drift: the currently installed Codex package changes, while the managed bundled marketplace / plugin cache / active version pointers can still reflect older state. The tool resolves the currently installed official package, validates the bundled marketplace and versioned plugin state, and only performs a repair when it detects an inconsistency. It also creates backups/rollback data before changing user-side Codex state.

This is a user-side recovery/diagnostic workaround, not an upstream fix, and I don’t want to overstate its scope. It does not patch or take ownership of WindowsApps files and does not bypass sandbox, enterprise, or browser security policies. For the specific stale bundled-marketplace/cache failure described in this issue, though, it may be useful for affected Windows users while the updater behavior is being fixed upstream.

Confirmed again on Codex AppX 26.825.6671.0 (2026-08-30), including the Windows/WSL path-shape mismatch described here.

On the affected Windows-native process, the persisted bundled marketplace source is:

/mnt/c/Users/<user>/.codex/.tmp/bundled-marketplaces/openai-bundled

The ordinary marketplace list silently omits openai-bundled. Supplying only a read-only config override with the equivalent C:\Users\<user>\... path immediately restores marketplace visibility, so the bundled payload itself exists.

The source advertises Browser/Chrome 26.825.51511, while the cache remains on Browser 26.727.40816 and Chrome 26.825.32147. The expected browser-service.mjs under 26.825.51511 is absent. Reinstalling from Settings > Computer Use, updating every Store app, restarting repeatedly, and reinstalling the ChatGPT Chrome extension did not reconcile it.

The current downstream error from Chrome extension 1.2.27268.51612 is:

Codex app-server manifest entry is missing required path nodePath

Host inspection shows the Chrome extension and native-host registration are present, but Codex's generated chrome-native-hosts-v2.json has stale historical runtime targets and no current 26.825 entry.

This is strong evidence that startup/update should normalize and validate the persisted marketplace source in the host context, then refresh the plugin cache and app-server manifest together. Reinstalling only the extension cannot fix the upstream versioned-path state.

I can reproduce a related issue on a newer Windows Codex build, and I was able to narrow it down further.

Environment

Codex Desktop package: 26.917.8451.0
Bundled Browser plugin: 26.917.62051
Embedded CLI: codex-cli 0.155.0-alpha.9.2
Platform: Windows x64 / packaged Codex Desktop app

My CODEX_HOME is:

E:\CodexData

and:

C:\Users\<user>\.codex

is a Junction pointing to E:\CodexData.

Initial bundled marketplace problem

Initially, Desktop logs repeatedly showed the managed openai-bundled marketplace reconciliation failing because the same underlying marketplace directory was represented by two different paths:

\\?\C:\Users\<user>\.codex\.tmp\bundled-marketplaces\openai-bundled

vs.

E:\CodexData\.tmp\bundled-marketplaces\openai-bundled

The relevant error was essentially:

marketplace 'openai-bundled' is already added from a different source; remove it before adding this source

followed by bundled_plugins_reconcile_failed.

The recovery that worked was:

Close Codex completely.
Use the embedded CLI to run:
codex plugin marketplace remove openai-bundled
Do NOT manually add it again, because openai-bundled is a reserved Desktop-managed marketplace.
Start Codex Desktop and let Desktop recreate/re-register the managed marketplace itself.

After this, openai-bundled persisted correctly across restart at:

E:\CodexData\.tmp\bundled-marketplaces\openai-bundled

and Browser / Chrome / Computer Use were listed as installed and enabled.

This also fixed a Chrome extension native-host error I had previously been seeing:

Codex app-server manifest entry is missing required path nodePath

The current Node and Node REPL runtime paths were then selected correctly.

Remaining Browser skill problem

There is still a reproducible Browser-specific problem after the marketplace repair.

Immediately after reinstalling:

browser@openai-bundled

the following file exists:

E:\CodexData\plugins\cache\openai-bundled\browser\26.917.62051\skills\control-in-app-browser\SKILL.md

and its SHA256 is identical to the copy in the managed bundled marketplace source.

At that point:

codex debug prompt-input "Check whether Browser skill is available. Do not use it."

correctly contains:

browser:control-in-app-browser

in <skills_instructions>.

However, after restarting Codex Desktop, the Browser skill disappears again.

The Browser skill directory/file is missing from the installed plugin cache, while other bundled skills such as Computer Use remain present.

plugin list --marketplace openai-bundled

can still report:

browser@openai-bundled installed, enabled 26.917.62051

even though control-in-app-browser/SKILL.md is no longer present and the Browser skill is not injected into a new session.

Reliable temporary workaround

While Codex Desktop is running:

codex plugin remove browser@openai-bundled

followed by:

codex plugin add browser@openai-bundled

immediately restores:

skills\control-in-app-browser\SKILL.md

and debug prompt-input immediately exposes:

browser:control-in-app-browser

again.

No Desktop restart is required.

After another Desktop restart, the skill can disappear again.

Additional observation

Even when browser:control-in-app-browser is missing from the session skill catalog, the Codex In-app Browser backend (iab) itself can still be usable through Computer Use / cua_repl.

I confirmed that a read-only authenticated browser task could be completed through the IAB backend even though the session initially reported that browser:control-in-app-browser was not in the available skill list.

So in my case these appear to be separate layers:

bundled plugin / Node / IAB runtime can be healthy
Browser skill cache/discovery can still be broken after restart

The Browser-specific remove -> add operation repairs the skill exposure until the next restart.

This seems related to #46744 and possibly the managed bundled marketplace/cache behavior discussed in #40059.

I can provide sanitized log excerpts if useful. I have not attached the full Desktop logs because they contain local usernames, filesystem paths, private ChatGPT project IDs/titles, and conversation URLs.

Navigation Menu

Repository navigation

🩹 Bundled Browser/Chrome/Computer Use plugins disappear after Windows app updates due to stale bundled marketplace path #30270

Bundled Browser/Chrome/Computer Use plugins disappear after Windows app updates due to stale bundled marketplace path

Environment

Summary

Expected Behavior

Actual Behavior

Reproduction Pattern

Evidence / Diagnostics

Workaround

Requested Fix

Privacy / Security Note

Environment

Confirmed update conflict

Chrome uninstall failure

Recovery performed

Requested behavior

Environment

Initial bundled marketplace problem

Remaining Browser skill problem

Reliable temporary workaround

Additional observation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

🩹 Bundled Browser/Chrome/Computer Use plugins disappear after Windows app updates due to stale bundled marketplace path #30270

Description

Bundled Browser/Chrome/Computer Use plugins disappear after Windows app updates due to stale bundled marketplace path

Environment

Summary

Expected Behavior

Actual Behavior

Reproduction Pattern

Evidence / Diagnostics

Workaround

Requested Fix

Privacy / Security Note

Activity

github-actions commented on Jun 26, 2026

wva2ccyk-prog commented on Jun 26, 2026

Nicolas0315 commented on Jun 27, 2026

wva2ccyk-prog commented on Jun 27, 2026

xiaokangzaina commented on Jun 27, 2026

xiaokangzaina commented on Jun 27, 2026

wva2ccyk-prog commented on Jun 27, 2026

xiaokangzaina commented on Jun 29, 2026

matzoka commented on Jul 7, 2026

NotoriousNDC commented on Jul 16, 2026

dagagemaster commented on Jul 16, 2026

Environment

Confirmed update conflict

Chrome uninstall failure

Recovery performed

Requested behavior

zemeng5208 commented on Aug 12, 2026

th3nolo commented on Aug 30, 2026

pennnpenn commented on Sep 23, 2026

Environment

Initial bundled marketplace problem

Remaining Browser skill problem

Reliable temporary workaround

Additional observation

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions