Codex Security “Start scan” times out and leaves an orphaned scan-start waiter

Open 💬 4 comments Opened Jul 10, 2026 by infraveil

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:

  1. 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.”

  1. The agent opens the Codex Security setup workspace for the repository in standard mode.
  2. Click “Start scan.”
  3. The UI shows:

“Action needed — MCP error -32001: Request timed out”

  1. Retry or reopen the same setup workspace. The plugin responds:

“A scan-start waiter already exists for session …”

  1. 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.

View original on GitHub ↗

4 Comments

ASTXRTYS · 1 month ago

Independent macOS reproduction of the scan-start timeout/orphaned waiter behavior.

Environment

  • macOS 15.6 (24G84), Apple Silicon (arm64)
  • Codex Desktop / embedded CLI 0.144.0-alpha.4
  • Codex primary runtime 26.709.11516
  • Codex Security plugin 0.1.11
  • ChatGPT Pro
  • Thread ID: 019f49a3-7258-7591-9e98-55a167bafed5

Observed behavior

On 2026-07-10 at approximately 01:32 UTC, clicking Start scan left the Security UI at Starting scan... and then displayed:

Action needed
MCP error -32001: Request timed out

Showing the last known scan state
MCP error -32001: Request timed out

The local rollout log then records a direct retry of await_codex_security_scan_start returning:

A scan-start waiter already exists for session 6ebe97c8-f28c-4fe0-868e-166de39548a8.

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.

USS-Parks · 1 month ago

Independent Windows reproduction with additional recovery and UI-state defects.

Environment

  • Codex Windows app package: 26.707.9981.0
  • Codex Security plugin: 0.1.11
  • Scan mode: Deep
  • Target: whole non-Git workspace root
  • Scan workspace session: 59023b8c-98f5-4b49-b808-119a93534093

Observed behavior

  1. Clicking Start scan produced Action needed — MCP error -32001: Request timed out.
  2. Retrying await_codex_security_scan_start returned:

A scan-start waiter already exists for session 59023b8c-98f5-4b49-b808-119a93534093.

  1. No durable scan ID was delivered, and no scan began.
  2. Calling 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.
  3. The reopened tool response reported 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.

USS-Parks · 1 month ago

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.

TharunCST · 29 days ago

Yes please, do we''ve an update ? or any fixes to perform codex security scans ?