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

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

Just use t3code
And ever so often I keep seeing that connection alert.

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

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.

Sigh, 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.

I 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

@t3dotgg

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 🤞🏼

happening 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 😂

@juliusmarminge

I 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

@ramifara

@ramifara Just read the pr you attached to your comment, that pretty much sums it up, but you closed it so meaning we still waiting for an official fix.

@Sensei85

@Sensei85 for me this also happened without using remote machines. just installed it on windows without any remote stuff going on.

@Sensei85 for me this also happened without using remote machines. just installed it on windows without any remote stuff going on.

I guess the issue is widespread than I thought.

I am also getting it without remote machines

Having 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.start remained 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 ps snapshots reached 12.5 seconds and timed out.
Local /.well-known/t3/environment requests 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.getConfig completed in 21 ms.

The fast server.getConfig recovery 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.

Windows 11 26H2 with latest 0.1.7 still an issue.

Navigation Menu

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

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

andyalv commented on Jul 7, 2026

Sensei85 commented on Jul 8, 2026

kimnzl commented on Jul 9, 2026

bslatner commented on Jul 9, 2026

bayerju commented on Jul 10, 2026

nickmatteo commented on Jul 11, 2026

ramifara commented on Jul 11, 2026

ramifara commented on Jul 11, 2026

GoblinRules commented on Jul 11, 2026

ramifara commented on Jul 11, 2026

Sensei85 commented on Jul 12, 2026

Sensei85 commented on Jul 12, 2026

bayerju commented on Jul 12, 2026

Sensei85 commented on Jul 12, 2026

kimnzl commented on Jul 12, 2026

fairtradepanic commented on Jul 18, 2026

fairtradepanic commented on Jul 18, 2026

christopher-buss commented on Jul 28, 2026

bzbetty commented on Jul 28, 2026

smitty7349 commented on Jul 28, 2026

rickycambrian commented on Aug 7, 2026

t3dotgg commented on Aug 28, 2026

leoscha commented on Aug 29, 2026

netpro2k commented on Aug 31, 2026

myn commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions