What version of the Codex App are you using (From “About Codex” dialog)?
26.721.41059 (build 5848), bundled codex-cli 0.146.0-alpha.3.1
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm (macOS 26.5.2)
What issue are you seeing?
On every Codex App startup, bundled-plugin reconciliation runs twice in the same app process with the same reason=startup. The second request is queued while the first is running, but it is not deduplicated after the first completes.
Each pass rewrites the complete bundled marketplace from the signed app bundle (about 70 MiB on this installation) to ~/.codex/.tmp/bundled-marketplaces/openai-bundled, even though the marketplace is already registered (alreadyAdded=true). It then reinstalls the browser and chrome plugins. The first pass reports their state as unknown; the immediately following pass reports them as outdated and installs them again.
This causes roughly 100-220 MiB of avoidable disk writes per ordinary app launch. During an automatic app update, the old process and relaunched process each performed both passes, amplifying an already write-heavy update. A hardware-level IOKit counter measured 3.28 GiB of physical writes in that 10-minute update/startup window. That total includes the 1.4 GiB app replacement and APFS/update overhead, so it is not attributed solely to plugins; however, file timestamps show 356.6 MiB of plugin marketplace/cache/app-server files rewritten during the same startup sequence.
This is not session JSONL or SQLite log growth. It is deterministic bundled-plugin materialization and installation work during startup.
Sanitized log sequence from one normal post-update process:
23:45:08.277 bundled_plugins_reconcile_started queued=false reason=startup
23:45:09.077 plugin_marketplace_folder_write_succeeded pluginCountBeforeWrite=7 pluginCountAfterWrite=7
23:45:09.088 plugin_marketplace_add_succeeded alreadyAdded=true
23:45:09.765 bundled_plugin_install_requested pluginName=browser reason=unknown
23:45:09.835 plugin_install_succeeded pluginName=browser
23:45:09.864 bundled_plugin_install_requested pluginName=chrome reason=unknown
23:45:09.925 plugin_install_succeeded pluginName=chrome
23:45:10.235 plugin_marketplace_sync_completed pluginsInstalledBeforeWrite=5 pluginsInstalledAfterWrite=5
23:45:10.351 bundled_plugins_reconcile_completed reason=startup
23:45:10.351 bundled_plugins_reconcile_started queued=true reason=startup
23:45:10.958 plugin_marketplace_folder_write_succeeded pluginCountBeforeWrite=7 pluginCountAfterWrite=7
23:45:10.965 plugin_marketplace_add_succeeded alreadyAdded=true
23:45:11.278 bundled_plugin_install_requested pluginName=browser reason=outdated
23:45:11.370 plugin_install_succeeded pluginName=browser
23:45:11.403 bundled_plugin_install_requested pluginName=chrome reason=outdated
23:45:11.470 plugin_install_succeeded pluginName=chrome
23:45:11.746 plugin_marketplace_sync_completed pluginsInstalledBeforeWrite=5 pluginsInstalledAfterWrite=5
23:45:13.620 bundled_plugins_reconcile_completed reason=startup
The two passes use the same local app-server, source directory, target directory, marketplace name, and app process. They are not local/remote or primary/backup phases.
What steps can reproduce the bug?
- Use Codex App with the bundled
browser and chrome plugins available/installed.
- Quit and launch Codex App normally.
- Open the startup log under
~/Library/Logs/com.openai.codex/.
- Search for
bundled_plugins_reconcile_started, plugin_marketplace_folder_write_succeeded, and bundled_plugin_install_requested.
- Observe two serialized reconciliation runs with
reason=startup, two complete marketplace writes, and two installs each for browser and chrome.
I observed the same two-pass sequence across multiple ordinary launches, not only during an update.
What is the expected behavior?
Only one bundled-plugin reconciliation should run per app-server/app startup. Identical queued startup requests should be coalesced or discarded after a successful in-flight reconciliation.
If the bundled marketplace materialization key/version and packaged contents have not changed, startup should not remove and rewrite the entire target directory. Plugins that were just installed successfully should not immediately be classified as outdated and reinstalled.
Additional information
The first reconciliation starts immediately next to Browser Use backend initialization, and a second identical startup request is queued while it is running. This suggests two startup callers converge on a serializer that queues but does not deduplicate equivalent work. That is an inference from the event order; the logs conclusively show the duplicate queued execution.
Suggested safeguards:
- Coalesce identical pending reconciliation requests by host/marketplace/reason.
- Recheck the materialization key after an in-flight reconciliation completes before executing queued work.
- Skip marketplace replacement when packaged version/content digest is unchanged.
- Make plugin installation state updates atomic so a just-installed plugin cannot be seen as
unknown/outdated by the next pass.
All paths and identifiers above are sanitized. No conversation or project data is involved.
What version of the Codex App are you using (From “About Codex” dialog)?
26.721.41059 (build 5848), bundled
codex-cli 0.146.0-alpha.3.1What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm(macOS 26.5.2)What issue are you seeing?
On every Codex App startup, bundled-plugin reconciliation runs twice in the same app process with the same
reason=startup. The second request is queued while the first is running, but it is not deduplicated after the first completes.Each pass rewrites the complete bundled marketplace from the signed app bundle (about 70 MiB on this installation) to
~/.codex/.tmp/bundled-marketplaces/openai-bundled, even though the marketplace is already registered (alreadyAdded=true). It then reinstalls thebrowserandchromeplugins. The first pass reports their state asunknown; the immediately following pass reports them asoutdatedand installs them again.This causes roughly 100-220 MiB of avoidable disk writes per ordinary app launch. During an automatic app update, the old process and relaunched process each performed both passes, amplifying an already write-heavy update. A hardware-level IOKit counter measured 3.28 GiB of physical writes in that 10-minute update/startup window. That total includes the 1.4 GiB app replacement and APFS/update overhead, so it is not attributed solely to plugins; however, file timestamps show 356.6 MiB of plugin marketplace/cache/app-server files rewritten during the same startup sequence.
This is not session JSONL or SQLite log growth. It is deterministic bundled-plugin materialization and installation work during startup.
Sanitized log sequence from one normal post-update process:
The two passes use the same local app-server, source directory, target directory, marketplace name, and app process. They are not local/remote or primary/backup phases.
What steps can reproduce the bug?
browserandchromeplugins available/installed.~/Library/Logs/com.openai.codex/.bundled_plugins_reconcile_started,plugin_marketplace_folder_write_succeeded, andbundled_plugin_install_requested.reason=startup, two complete marketplace writes, and two installs each forbrowserandchrome.I observed the same two-pass sequence across multiple ordinary launches, not only during an update.
What is the expected behavior?
Only one bundled-plugin reconciliation should run per app-server/app startup. Identical queued startup requests should be coalesced or discarded after a successful in-flight reconciliation.
If the bundled marketplace materialization key/version and packaged contents have not changed, startup should not remove and rewrite the entire target directory. Plugins that were just installed successfully should not immediately be classified as
outdatedand reinstalled.Additional information
The first reconciliation starts immediately next to Browser Use backend initialization, and a second identical startup request is queued while it is running. This suggests two startup callers converge on a serializer that queues but does not deduplicate equivalent work. That is an inference from the event order; the logs conclusively show the duplicate queued execution.
Suggested safeguards:
unknown/outdatedby the next pass.All paths and identifiers above are sanitized. No conversation or project data is involved.