Summary
On Windows, T3 Code showed the Codex provider as Not found. Sending a message failed with:
ProviderAdapterProcessError: Provider adapter process error (codex)
Codex App Server process exited with code 1
This was hard to diagnose because T3 Code did not surface the stderr from the underlying codex app-server process.
I do not have a minimal repro, but I wanted to share the diagnostic path in case it helps improve the provider error handling.
Environment
- OS: Windows
- T3 Code:
0.0.21
- Codex CLI:
codex-cli 0.128.0-alpha.1
- Shell: PowerShell
- Codex install source: Codex desktop app / Windows app package
Diagnostics
codex --version worked, but starting the app server directly failed:
codex app-server --listen ws://127.0.0.1:0
Output:
Error: error loading default config after config error: Access is denied. (os error 5)
On my machine, I found unreadable Codex sandbox state under:
C:\Users\<me>\.codex\.sandbox-secrets*
I also found that codex was not resolving to the expected shim path:
%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe
Instead, it appeared to resolve to a packaged executable under:
C:\Program Files\WindowsApps\...
I am not sure whether T3 Code used the same resolution path internally, because the startup error did not include the executable path or stderr.
Workaround
I moved the unreadable .sandbox-secrets* entries out of ~\.codex, restored the Codex shim so that where.exe codex resolved to:
%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe
Then I verified:
where.exe codex
codex --version
codex app-server --listen ws://127.0.0.1:0
After fully restarting T3 Code, the Codex provider appeared and messaging worked.
Request
Please surface the underlying codex app-server stderr and the resolved codex executable path when provider startup fails.
In this case, the T3 UI only showed that the provider adapter exited. The actionable error was only visible after manually running codex app-server.
Possibly related
I found a few adjacent Windows/Codex provider issues, but none looked like an exact duplicate:
Summary
On Windows, T3 Code showed the Codex provider as
Not found. Sending a message failed with:This was hard to diagnose because T3 Code did not surface the stderr from the underlying
codex app-serverprocess.I do not have a minimal repro, but I wanted to share the diagnostic path in case it helps improve the provider error handling.
Environment
0.0.21codex-cli 0.128.0-alpha.1Diagnostics
codex --versionworked, but starting the app server directly failed:Output:
On my machine, I found unreadable Codex sandbox state under:
I also found that
codexwas not resolving to the expected shim path:Instead, it appeared to resolve to a packaged executable under:
I am not sure whether T3 Code used the same resolution path internally, because the startup error did not include the executable path or stderr.
Workaround
I moved the unreadable
.sandbox-secrets*entries out of~\.codex, restored the Codex shim so thatwhere.exe codexresolved to:Then I verified:
After fully restarting T3 Code, the Codex provider appeared and messaging worked.
Request
Please surface the underlying
codex app-serverstderr and the resolvedcodexexecutable path when provider startup fails.In this case, the T3 UI only showed that the provider adapter exited. The actionable error was only visible after manually running
codex app-server.Possibly related
I found a few adjacent Windows/Codex provider issues, but none looked like an exact duplicate:
ProviderAdapterProcessError, but likely a different failure mode: JSON parsingInitializing agent...rather thanAccess is denied.