Repository navigation
Persistent "Codex CLI not found" error after installation of codex CLI #372
Description
Problem Description
If the application is launched without the Codex CLI (codex) installed or available in the system PATH, an error notification correctly appears when adding a project. However, after installing the CLI and verifying that the chat functionality works, the error message remains visible on the screen with no way to dismiss or close it.
Steps to Reproduce
- Ensure Codex CLI (
codex) is not installed or is not in your system PATH. - Open T3 Code.
- Add a project.
- Observe the error notification popping up (expected behavior).
- Install the Codex CLI while the app is running.
- Verify that the chat feature now works.
Actual Result
The initial error notification remains on the screen. There is no close/dismiss button, and it does not disappear automatically even after the underlying issue is resolved.
Expected Result
The error should either:
- Provide a way to manually dismiss/close the notification.
- Automatically clear itself once the application detects the CLI is available.
My Device
- MacBook Air Apple M4
- 16 GB Ram
Activity
basilk15 commentedon Mar 11, 2026
same issue
basilk15 commentedon Mar 11, 2026
Tried to fix path issues and see where the codex bin lives, but still no luck.
utkuoymak commentedon Mar 13, 2026
I have the same issue, codex is installed via homebrew. If I enter the path in settings, it works but still seeing the error for no reason
PaulHoza commentedon Mar 13, 2026
Same problem here on Linux (Pop_OS/debian). I'm using the AppImage build of T3C, so it doesn't see the Codex path in any way I tried to get it into the PATH. Chat does work when I add the paths into settings manually, but the status health message stays up.
I wondered if it's a health status check done in multiple places, so something checks for status.provider matching PATH to decide to render the banner, which "fails", even though the settings are correct so the status is actually valid. If it's being checked in multiple places, they'd all need to check against settings, not just a direct PATH check.
Having one place check the status and then the banner status checks THAT, I mean.
VERY BRIEF skim of code sees ProviderHealthBanner and ProviderHealthTest, et. al.
Sorry if this is noise.. I am away from my workstation and wanted to post this thought. I'll see if I can check myself later, but this stuff is out of my wheel house mostly. Just hoping the idea helps.
PaulHoza commentedon Mar 14, 2026
OK, I think I was "right"-ish? I'll just leave a note here in case someone can fix this. I'm not a "PR kind of guy", so I'd rather just report this:
There are indeed two separate code paths, it seems:
So, when users set a custom codexBinaryPath in settings, sessions work but the health check fails because it uses the default PATH lookup.
I'm not sure what a good fix is for the style of the app, but clearly the Health Check needs to use the settings path/command, at least. I don't see a "retry" mechanism, so could maybe add that.
Hope this helps!
Cheers.
DrLehman commentedon Mar 15, 2026
Link #301 #234
juliusmarminge commentedon Jun 9, 2026
Closing as a duplicate of #197. Both report that the Codex provider warning remains visible after the CLI is installed and working, with no way to dismiss or refresh it.