externalAgentConfig/detect returns empty on Windows, silently disabling Claude Code import sync (0.147.0)

Summary

externalAgentConfig/detect returns {"items": [], "connectors": []} on Windows even though Claude Code is installed and ~3,900 transcripts are present on disk. Because the Settings → Import panel and the "Keep imports in sync" background job are both driven by that call, the app has no source to sync from and silently stops importing. Nothing errors, and import/readHistories still runs at every launch reading past imports, so the feature continues to look healthy while no new session ever arrives.

externalAgentConfig/import still works correctly for the exact same transcripts. That is what makes me fairly confident the problem is isolated to detection, not to the importer or to the transcripts themselves.

Environment

• codex-cli 0.147.0 (npm @openai/codex, vendored codex-win32-x64 binary)
• Windows 11 Pro for Workstations, 10.0.26200
• Claude Code installed, transcripts at C:\Users\<user>\.claude\projects\ — 476 project directories, 3,892 .jsonl transcripts

Reproduction

Drive codex app-server over stdio:

--> {"id":1,"method":"initialize","params":{"clientInfo":{"name":"detect-probe","title":"detect probe","version":"1.0.0"}}}
<-- (initialize OK)
--> {"id":2,"method":"externalAgentConfig/detect","params":{}}
<-- {"id":2,"result":{"items":[],"connectors":[]}}

Expected: items populated with the Claude Code source, as it must have been previously (see below).

Evidence that this is a regression

~/.codex/external_agent_session_imports.json records every import with an imported_at. Grouped by UTC day, autosync was importing steadily and then stopped dead:

2026-08-09   52
2026-08-10   34
2026-08-11   99
2026-08-12   60
2026-08-13   50
2026-08-14   28
2026-08-15   34
2026-08-16    8
2026-08-17   27
2026-08-18    0   <- autosync stops here, nothing since

(Records dated 08-19 and later are from a local script I wrote to work around this, driving externalAgentConfig/import directly — not autosync.)

The same file's detected_connector_records array is [].

Why I think detection specifically is at fault

Calling externalAgentConfig/import directly with itemType: "SESSIONS" and explicit session paths imports those same transcripts successfully — 651 records and counting. So the transcripts are present, readable, parseable, and acceptable to the importer. Only detect fails to see them.

One incidental finding while building that workaround, in case it is the same root cause: import requires source paths carrying the Windows \?\ extended-length prefix, exactly as they are stored in external_agent_session_imports.json. Given an ordinary C:\Users\... path, import returns both successes: [] and failures: [] and logs nothing — a silent no-op with no error surface. If detect builds paths without that prefix somewhere in its pipeline, that would explain an empty result with no diagnostics. I have not verified that connection; it is a guess offered only because the silent-empty failure shape is identical.

Impact

Silent, not loud. Users lose Claude Code import sync with no error, no notification, and a Settings panel that appears functional — the failure is only visible if you notice new sessions never showing up, or go looking at the RPC.

Suggested handling

Even short of a fix, having detect surface why it found nothing (path scanned, count seen, reason rejected) would turn this from an invisible failure into a diagnosable one. The same applies to import's empty-successes-empty-failures response.

Start by tracing the app-server stdio entry point for externalAgentConfig/detect on Windows and compare it with externalAgentConfig/import, using the paths in external_agent_session_imports.json. Check the handling of Claude Code transcripts and the Windows \?\ path prefix. Done means detect returns the installed Claude Code source and autosync can discover new sessions instead of returning empty arrays.