Codex Security “Start scan” times out and leaves an orphaned scan-start waiter
What version of the Codex App are you using (From “About Codex” dialog)?
Codex desktop 26.707.3563, Windows
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64
What issue are you seeing?
await_codex_security_scan_start remained pending after Start scan, and eventually times out.
What steps can reproduce the bug?
Environment:
- Windows: Microsoft Windows NT 10.0.26100.0 x64
- Codex desktop: 26.707.3563
- Codex Security plugin: 0.1.11
Steps to reproduce:
- In Codex desktop, open a repository and ask:
“[@codex-security](plugin://codex-security@openai-curated-remote) Run a Codex Security scan on this repository. U have full rights.”
- The agent opens the Codex Security setup workspace for the repository in standard mode.
- Click “Start scan.”
- The UI shows:
“Action needed — MCP error -32001: Request timed out”
- Retry or reopen the same setup workspace. The plugin responds:
“A scan-start waiter already exists for session …”
- No scan ID is returned, so the scan cannot begin.
Expected:
Clicking Start scan should promptly return a durable scan ID and allow the security scan to continue.
Actual:
The start-scan handoff remains pending until the MCP client times out. It leaves an orphaned waiter, which blocks retries.
Reproduction snippet:
const workspace = await tools.mcp__codex_security__open_codex_security_workspace({
targetPath: "C:\\Users\\mt\\Documents\\Programming\\InfraveilNew",
mode: "standard",
scope: ".",
targetTitle: "InfraveilNew"
});
await tools.mcp__codex_security__await_codex_security_scan_start({
sessionId: "a62c9885-aadb-4683-918b-32c1017e75f5"
});
// Click Start scan in the rendered workspace.
// Result: MCP error -32001: Request timed out.
Session ID:
a62c9885-aadb-4683-918b-32c1017e75f5
Evidence:
- The initial await call began at 2026-07-10T00:01:51Z.
- A retry returned: “A scan-start waiter already exists for session a62c9885-aadb-4683-918b-32c1017e75f5.”
- Desktop logs later recorded related MCP calls lasting 201,269 ms and 255,930 ms.
- Setup was saved, but no durable scan ID was delivered.
Token/context information at the time:
- Model context window: 353,400 tokens.
- Usage was below quota; no rate-limit event occurred.
- The failure occurred before scan analysis, so repository size/token usage was not a factor.
What is the expected behavior?
After I click Start scan, Codex Security should immediately confirm the launch, return a durable scan ID to the active Codex task, and begin the standard repository security scan. The setup should not time out, and retrying should not leave or encounter a stale “scan-start waiter.”
Additional information
This was reproducible in the Codex desktop app on Windows and was not caused by repository access, permissions, rate limits, or a broad Codex outage. The workspace setup saved successfully; only the Start-scan handoff failed.
The plugin’s scan-start wait request remained pending after the button click. Desktop logs show related MCP calls eventually completing after roughly 201–256 seconds, which is consistent with the client timing out before the long-polling handoff completed. No scan ID was returned, so the scan never began.
This message was created by Codex which directly scanned for the root cause, etc.
4 Comments
Independent macOS reproduction of the scan-start timeout/orphaned waiter behavior.
Environment
arm64)0.144.0-alpha.426.709.115160.1.11019f49a3-7258-7591-9e98-55a167bafed5Observed behavior
On 2026-07-10 at approximately 01:32 UTC, clicking Start scan left the Security UI at Starting scan... and then displayed:
The local rollout log then records a direct retry of
await_codex_security_scan_startreturning:That result was marked
isError: true; no usable scan ID was returned. Repeated Start Scan attempts remained stuck rather than replacing or clearing the waiter.A newer primary runtime (
26.709.11516) was installed shortly afterward. After a full application restart, a later deep scan on the same Mac successfully passed scan start. That suggests stale in-process plugin/MCP state or a runtime/plugin mismatch may be relevant, but it does not establish the root cause.This indicates the problem is not Windows-only. The important recovery defect is that after the timeout, the waiter remains registered and retries cannot self-heal or cancel it.
Independent Windows reproduction with additional recovery and UI-state defects.
Environment
26.707.9981.00.1.1159023b8c-98f5-4b49-b808-119a93534093Observed behavior
Action needed — MCP error -32001: Request timed out.await_codex_security_scan_startreturned:A scan-start waiter already exists for session 59023b8c-98f5-4b49-b808-119a93534093.open_codex_security_workspace({ sessionId })to reopen the same saved workspace created a second visible Codex Security tab instead of focusing/reusing the existing tab.setup.submitted: true, while the visible UI still showed the setup form and an enabled Start scan button. This indicates backend/UI state divergence in addition to the orphaned waiter.The attached screenshot shows the duplicate Codex Security tabs and the contradictory setup UI after the reopen attempt.
I've reproduced this error in several new sessions over the past 48hrs. Can confirm it is persistent and does not remedy with uninstall/reinstall or end-task/reboot.
Yes please, do we''ve an update ? or any fixes to perform codex security scans ?