Windows ChatGPT/Codex 26.707: ~3.4s orchestration overhead per local tool call after desktop app migration
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.72221
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
What version of the Codex App are you using?
ChatGPT/Codex desktop app package: 26.707.9981.0
Bundled command runner observed: codex-command-runner-0.144.2
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Windows x64, PowerShell
What issue are you seeing?
After upgrading from the standalone Codex desktop app to the new unified ChatGPT desktop app, agentic coding tasks became significantly slower.
Model-only tasks such as code Q&A and solution discussions remain fast. The regression appears specifically when Codex invokes local tools to read, search, edit, or test files.
Even a no-op command has several seconds of end-to-end overhead.
Steps to reproduce
- Open a local workspace in the Windows desktop app.
- Start a new Codex task.
- Ask Codex to run a no-op command:
```cmd
cmd /c exit 0
What steps can reproduce the bug?
<html>
<body>
This is reproducible in a newly created Codex task and does not appear to depend on a long conversation or a nearly full context window.
Session ID: 019f605f-2b95-7e90-b560-bd3dcb329fcc
Steps to reproduce:
- Launch the unified ChatGPT desktop app on Windows.
- Open Codex and select any local workspace.
- Create a new task.
- Ask Codex to execute the following no-op command three times sequentially:
``cmdcmd /c exit 0` three times sequentially. For each invocation,
cmd /c exit 0</code></pre><p> Example prompt:</p><pre><code>Run
record the command runner's reported runtime and the end-to-end
elapsed time from tool-call submission until its result is returned.
Do not perform any other operations.</code></pre><ol start="5"><li>Compare the command's reported runtime with the end-to-end duration of each tool call.</li></ol><p>Observed results:</p><div><div>
Run | Reported command runtime | End-to-end duration
-- | -- | --
1 | 0.707 s | 4.390 s
2 | 0.881 s | 4.243 s
3 | 0.902 s | 4.581 s
</div></div><p>Total end-to-end duration for three no-op commands: <code>13.216 s</code>.</p><p>Each command therefore incurred approximately <code>3.4 s</code> of overhead outside the actual command execution.</p><p>During the reproduction, the app repeatedly started or used:</p><ul><li><code>codex-windows-sandbox-setup</code></li><li><code>codex-command-runner-0.144.2</code></li></ul><p>Model-only questions in the same task remained responsive. The slowdown mainly appeared when local tools were invoked.</p><h3>Session information</h3><ul><li>Session ID: <code>019f605f-2b95-7e90-b560-bd3dcb329fcc</code></li><li>Model: <code>gpt-5.6-sol</code></li><li>Reasoning effort: <code>medium</code></li><li>Model context window: <code>258,400</code> tokens</li><li>Input tokens in a request near the reproduction: approximately <code>41,599</code></li><li>Cached input tokens: approximately <code>32,512</code></li><li>Approximate active context usage: <code>16%</code></li><li>Codex weekly usage shown during the reproduction: <code>80%</code></li><li>Rate limit was not reached and no HTTP 429 error was shown</li></ul><h3>Impact</h3><p>A coding task normally requires many tool calls for reading files, searching references, applying patches, inspecting diffs, and running tests. The fixed overhead accumulates across these calls, causing small code or documentation changes to take 20–30 minutes.</p><h3>Notes</h3><p>A third-party Orca lifecycle hook was configured during the reproduction. Direct measurement of that hook averaged approximately <code>80 ms</code> per invocation. It may contribute a small amount of latency, but it does not appear sufficient to explain the observed 3–4 second overhead.</p><p>No private source code, authentication files, or complete unredacted logs are included.</p></div></div></div></div><!--EndFragment-->
</body>
</html>
What is the expected behavior?
Expected behavior
A completed no-op command should return with minimal additional overhead. Small file edits should not take 20–30 minutes because of accumulated per-tool-call latency.
Actual behavior
Each local tool invocation appears to incur approximately 3–4 seconds of fixed overhead beyond the command's own runtime.
Configuration
Model: gpt-5.6-sol
Reasoning effort: medium
Windows sandbox mode configured as elevated
A third-party Orca hook is configured for tool lifecycle events. Direct measurement of that hook averaged approximately 80 ms per invocation, so it may add some overhead but does not appear sufficient to explain the observed 3–4 second delay.
Additional information
This appears different from general model latency because normal code questions remain fast. It seems localized to the Windows desktop tool-call, sandbox, or command-runner orchestration path.
Potentially related:
#24336 — long post-tool thinking gaps and excessive context growth
#20214 — Windows desktop performance issues
I have intentionally excluded authentication files, private source code, complete configuration files, and unredacted local logs.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗