What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.727.51351
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
This is not solely a Computer Use installation failure or a Codex bundled-plugin problem. It occurs in the Chat surface of the unified Windows app. The same account and application have exposed Computer Use successfully in one Chat, while another Chat continues to display the tool as selectable but does not expose it to the active model. During the affected Chat, ChatGPT’s plugin-permission inspection reported several tools displayed by the composer as “not installed,” while at least one of them—Visualize—executed successfully in that same Chat.
What steps can reproduce the bug?
Feedback ID: no-active-thread-019fd878-f767-7591-aeb1-0345cf092ad0
What is the expected behavior?
Expected behavior:
A tool displayed as selectable in the current Chat should either be available to that Chat’s runtime or clearly marked unavailable before selection. Composer visibility, installation state, authorization state, runtime exposure, account gating, and Chat/Work/Codex applicability should not contradict one another.
The “What steps can reproduce the bug?” field could not be edited beyond its auto-populated Feedback ID, so the requested reproduction information follows below.
Feedback ID: no-active-thread-019fd878-f767-7591-aeb1-0345cf092ad0
Reproduction steps:
- Open the ChatGPT Windows desktop app.
- Enter a normal Chat conversation, not Work or Codex.
- Open the tool/plugin selector.
- Observe that tools including Computer, Browser, Visualize, Documents, PDF, Spreadsheets, Presentations, GitHub, Gmail, and Google Drive are displayed or selectable.
- Select or mention Computer in Chat.
- In one Chat session, Computer successfully accessed local Windows drives.
- In another Chat session in the same Windows app and account, Computer remained visible/selectable but was not exposed to the active runtime and could not be invoked.
- Query the app/plugin permission state:
- Documents, PDF, Spreadsheets, Presentations, GitHub, Gmail, and Google Drive are recognized.
- Computer, Browser, Visualize, Sites, Template Creator, OpenAI Templates, and a custom plugin may be reported as “not installed.”
- Observe that Visualize can nevertheless execute successfully while its plugin state reports “not installed.”
- Return to or create another ordinary Chat in the same Windows app and account. Observe that the displayed tool set and actual runtime exposure may differ between Chats without an explanatory availability state.
Actual result:
The Windows app exposes contradictory states for the same tool:
- visible/selectable in the composer;
- permissioned or authorized according to the app/plugin state;
- reported installed or not installed;
- exposed or withheld from the active runtime;
- usable in one Chat session but unavailable in another.
This creates a false affordance and repeated mode-switching/context-restoration loops. The assistant may also incorrectly tell the user that a capability is impossible even though it previously worked in Chat in the same Windows application.
Expected result:
A tool shown as selectable should either be usable in the current conversation or clearly marked unavailable before selection. Installation, authorization, runtime exposure, and Chat/Work/Codex availability should agree. Tool availability should remain stable and understandable across synchronized chats and projects.
No code snippet is applicable because this is a Windows desktop UI/runtime state-consistency bug.
Session ID:
No active thread/session ID was supplied by the feedback dialog beyond the Feedback ID above.
Token-limit usage:
The problem occurred after Work/Codex usage was exhausted, but ordinary Chat remained available. Exact usage percentage was not displayed.
Context-window usage:
Not applicable. The issue reproduces in ordinary Chat and is related to tool/runtime availability rather than conversation length.
Additional information
This appears to be a broader state-synchronization problem rather than a single missing plugin.
The Windows desktop app currently seems to maintain several separate states for each tool:
- Whether the tool is visible in the composer
- Whether it is installed or recognized by the plugin registry
- Whether the user has authorized it
- Whether the active model/runtime actually receives the tool
- Whether the tool is permitted in Chat, Work, or Codex
- Whether account usage limits or feature flags suppress it
Those states can disagree.
Observed examples:
- Computer was successfully invoked from an ordinary Chat session on August 5, 2026, and accessed local drives.
- Computer remained visible/selectable later, but was not exposed to the runtime in another ordinary Chat session.
- Visualize executed successfully in the affected Chat while ChatGPT’s plugin-permission inspection returned not_installed for Visualize.
- GitHub, Gmail, Google Drive, Documents, PDF, Spreadsheets, and Presentations were recognized by the permission registry, while several other tools shown in the UI were reported as not installed.
- Chats, projects, files, and context are synchronized across Chat, Work, and Codex, but capabilities are not synchronized or clearly identified.
This makes it difficult for either the user or the assistant to determine current capabilities reliably. It also causes repeated loops: attempt the task, discover a hidden capability boundary, switch modes, restore context, and retry.
A useful diagnostic view would expose, for every displayed tool:
- installed/available status
- authorization status
- runtime exposure status
- applicable product surfaces
- feature-flag or regional gating
- usage-limit gating
- reason unavailable
The app should not display a selectable tool unless it can either invoke it in the current conversation or explain before selection exactly why it is unavailable.
Related but not exact duplicate:
#25253
That issue documents bundled Browser/Computer Use plugins existing locally while runtime gating exposes only a subset. This report additionally concerns ordinary Chat, contradictory permission-registry results, composer false affordances, and session-to-session inconsistency.
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.727.51351
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
This is not solely a Computer Use installation failure or a Codex bundled-plugin problem. It occurs in the Chat surface of the unified Windows app. The same account and application have exposed Computer Use successfully in one Chat, while another Chat continues to display the tool as selectable but does not expose it to the active model. During the affected Chat, ChatGPT’s plugin-permission inspection reported several tools displayed by the composer as “not installed,” while at least one of them—Visualize—executed successfully in that same Chat.
What steps can reproduce the bug?
Feedback ID: no-active-thread-019fd878-f767-7591-aeb1-0345cf092ad0
What is the expected behavior?
Expected behavior:
A tool displayed as selectable in the current Chat should either be available to that Chat’s runtime or clearly marked unavailable before selection. Composer visibility, installation state, authorization state, runtime exposure, account gating, and Chat/Work/Codex applicability should not contradict one another.
The “What steps can reproduce the bug?” field could not be edited beyond its auto-populated Feedback ID, so the requested reproduction information follows below.
Feedback ID: no-active-thread-019fd878-f767-7591-aeb1-0345cf092ad0
Reproduction steps:
Actual result:
The Windows app exposes contradictory states for the same tool:
This creates a false affordance and repeated mode-switching/context-restoration loops. The assistant may also incorrectly tell the user that a capability is impossible even though it previously worked in Chat in the same Windows application.
Expected result:
A tool shown as selectable should either be usable in the current conversation or clearly marked unavailable before selection. Installation, authorization, runtime exposure, and Chat/Work/Codex availability should agree. Tool availability should remain stable and understandable across synchronized chats and projects.
No code snippet is applicable because this is a Windows desktop UI/runtime state-consistency bug.
Session ID:
No active thread/session ID was supplied by the feedback dialog beyond the Feedback ID above.
Token-limit usage:
The problem occurred after Work/Codex usage was exhausted, but ordinary Chat remained available. Exact usage percentage was not displayed.
Context-window usage:
Not applicable. The issue reproduces in ordinary Chat and is related to tool/runtime availability rather than conversation length.
Additional information
This appears to be a broader state-synchronization problem rather than a single missing plugin.
The Windows desktop app currently seems to maintain several separate states for each tool:
Those states can disagree.
Observed examples:
This makes it difficult for either the user or the assistant to determine current capabilities reliably. It also causes repeated loops: attempt the task, discover a hidden capability boundary, switch modes, restore context, and retry.
A useful diagnostic view would expose, for every displayed tool:
The app should not display a selectable tool unless it can either invoke it in the current conversation or explain before selection exactly why it is unavailable.
Related but not exact duplicate:
#25253
That issue documents bundled Browser/Computer Use plugins existing locally while runtime gating exposes only a subset. This report additionally concerns ordinary Chat, contradictory permission-registry results, composer false affordances, and session-to-session inconsistency.