Repository navigation
[Bug]: I keep getting failed to connect. My PC did not respond with a connection setup. It's pretty annoying. Why does it do that. #3746
Description
Activity
I've got the same issue, it happens a lot when trying to use the app, specially a little after I send a prompt. I have not found any solution/workaround about it.
Reacted by keithsimkin and Sam "Betty" McKoySigh, I updated codex cli but still issue persists.
I have to be timing it and type fast or copy paste prompt.On one of my PC's I am getting this just after creating a new thread. Not even being able to type. It is intermittent. Sometimes it happens. If I exit and restart several times it will eventually work.
Windows 10 + codex v0.143.0
I tried after disabling my AV/Anti Malware to rule that out.This happens to me constantly -- and by that, I mean the first time I open the app for the day and about every 10 minutes thereafter. Windows 11 Pro. Just started on the 0.0.28 release. Before that, it was completely fine. Now it's just genuinely unusable. When the message appears it takes several MINUTES to clear.
Reacted by Andrés Alvarez, Nicholas Mattteo, keithsimkin, Justin and RickyI had the same issue on my windows pc. I did not notice it on my linux machine though. To me it seemed to be a problem with high cpu usage, because of windows defender. At least it feels like it got better after i told windows defender to ignore t3 processes. But i did not really investigate it yet, since i like using my linux better anyway :D But i sometimes need windows for work.
Ya this is really bad almost make the app unusable which is super sad I tried both the alpha and nightly builds but i keep getting the error very often
yeah this is almost constant for me
claude remote and codex app remote are the same. this unstable connection issue seem to be something non of them can truely fix.
My host machine is a small mini pc connected to a kwm exactly the same as @t3dotgg mentioned on one of his latest videos, but this is truely unuseable. to make the problem even worst, I can not even use my kwm to connnect to the host t3code, because when remote connection fails it does not even allow working on the host machine. it seems like the architecture for connecting remote UI and local UI to the backend of the software is the same. so if one fails it fails for both.
@bslatner have you downgraded to see if it still works on older versions? I started using this feature on 0.0.28 so this has been my entiere experiance with it which is disapoiting :(
I could just SSH in and work though that but we all know that S**Ks
I just downgraded noth my host and client t3code back to 27 and all works perfectly, so what every the problem is it was intredused in 28. if they would have accepted contributions I might have burned this weekend to findout what is wrong, but i will just hope they will fix it in 29 🤞🏼
Reacted by Wisdom Agbottahhappening for me too, .27 seldom since .28 it became unusable and have tried all nighty's since.
I had better luck on the latest nightly Version 0.0.29-nightly.20260709.769, it still drops but it does not fully get stuck and unuseable like 28. I could not stay on 27, it does not work properly with GPT4.6 very well. I made a PR which fixed it on 28, but no way they would have merged it so I just closed it 😂
Reacted by Wisdom AgbottahI think I figured it out, not solved but I think I know what's happening. Turns out when you setup environments and connect T3 code to another machine running t3 code so you can work bi-directionally, as soon as that machine loses internet connection, t3 code is trying really hard to connect to that machine and unintentionally freezing up your current work being done on the thread that's not even on the remote machine. So T3 code is freezing up all threads regardless of whether the current active thread is on the host machine ie: current machine or on the remote environment. So, the fix Julius might implement is checking whether the thread is remote or not, leave it alone if it's not remote, or don't blocking the thread even if remote machine is temporarily unreachable. Maybe there's a reason for that design. @juliusmarminge
I am also getting it without remote machines
Reacted by Sam "Betty" McKoyHaving the same issue with OpenAI Codex (v0.144.5) on Windows 11 and T3 Version 0.0.28
The nightly build did not solve the issue for me
I'm having this despite network access being off.
still happens in 0.0.29, feel like its more likely if my machine is struggling for some reason (over active virus scan or cpu usage).
At least the textbox isn't disabled anymore, wish i could at least queue messages up for it while I had to wait.
See it on both Win 11 machines I use, don't think i've seen it in Linux (on a way less specced machine too)
same is happening to me. Prior to updating I was not experiencing this and now I am after the 0.0.29 update. Makes the app unusable for me currently. Network access is off. Even restarted my computer. :)
Same thing still happening constantly on 0.0.31. Often it disappears and I can send a message just for nothing at all to happen:
Turning off the network access or upgrading codex/claude doesn't change anything for me. It has become completely unusable, is there really no discovered fix for this? Crazy bad issue.
Note
🤖 GPT-5.6 Sol responding on behalf of Theo
Thanks for the detailed report. We believe this is fixed by PR #4241, PR #5561, and PR #5572.
PR #4241 keeps the composer editable during a disconnect, which a later comment confirms. PR #5561 tolerates delayed heartbeat replies and caches repeated discovery work. PR #5572 prevents an interrupted editor scan from blocking later reconnects. The last failure report used stable 0.0.31, before the two reconnect fixes. The separate cold-start failure also predates those fixes.
I'm closing this as fixed as part of an automated pass on all open issues.
If this still happens in a current build that includes PR #4241, PR #5561, and PR #5572, please reply with the T3 Code version and fresh logs or reproduction details, and we can reopen it.
Issue is still present on v0.0.36 (Apple Silicon)
Note
🤖 GPT-5.6 Sol responding on behalf of @netpro2k
I’m seeing this on macOS 15.6.1 arm64 with T3 Code 0.0.36 and Codex CLI 0.149.0. This is running our fork, based directly on upstream v0.0.36 and containing all three fixes cited above.
One relevant difference is how our packaged Desktop client runs locally: instead of launching its own embedded backend, it connects to a separately running T3 server on the same machine over
127.0.0.1. That adds local discovery and health monitoring around the connection, which could make a transient server stall more visible or cause the client to begin retrying sooner. However, it does not appear to explain the underlying stall—the existing WebSocket and unrelated local server operations became unresponsive while the same server process remained alive.In one captured incident:
- A new Codex app-server started at 19:51:01.
CodexSessionRuntime.startremained pending for 223.856 seconds.- During that interval, simple server filesystem reads rose from under 1 ms to as much as 9.9 seconds.
- Terminal
pssnapshots reached 12.5 seconds and timed out. - Local
/.well-known/t3/environmentrequests were interrupted after 3–8 seconds. - The existing WebSocket disconnected, but the T3 server PID did not exit.
- Shortly after Codex startup completed, the client reconnected and
server.getConfigcompleted in 21 ms.
The fast
server.getConfigrecovery suggests this was not the interrupted editor-discovery cache fixed by #5572. The failure also occurred entirely over loopback, so it was not dependent on T3 Connect, Tailscale, or loss of Internet connectivity.The machine was under substantial concurrent-agent pressure at the time: six active Codex sessions, a load average around 13 on 10 logical CPUs, and heavy disk activity. Codex startup may therefore be the source of the resource stall or another victim of it. The notable behavior is that, during provider initialization, unrelated server HTTP, WebSocket, filesystem, and process-polling operations all became slow enough to trigger the connection failure.
I can provide sanitized trace excerpts and exact timestamps if useful.
Before submitting
Area
apps/web
Steps to reproduce
Expected behavior
I don't know what changed in the latest update, but I keep getting that alert and when it happens I can't continue typing my prompt.
Actual behavior
I shouldn't also be seeing this annoying connecting pop ups that completely stops work.
Impact
Blocks work completely
Version or commit
0.0.28
Environment
Windows 11 + Codex
Logs or stack traces
Screenshots, recordings, or supporting files
image.png
Workaround
Found no work around