Restarting my T3 Code desktop client breaks running Codex threads on my remote machine connected through T3's managed SSH connection. When I reopen the client and reconnect, the threads show "Provider session did not survive a server restart. Send a new message to continue." Long-running agent work is interrupted and needs another message to continue. This previously worked for me: closing and reopening the client did not interrupt the remote work.
Observations
Read-only inspection of the remote server logs, persisted orchestration events, provider logs, and service state found the following on September 9, 2026. Times below are UTC:
| Time |
Observation |
| 07:15:31 |
SSH-managed server starts; one affected thread is marked errored with the restart message. |
| 10:10:52 |
Server starts; both affected threads are marked errored with the restart message. |
| 12:06:22 |
Another server start; both threads receive the same error again. |
The remote host had been up seven days. The kernel journal contained no OOM kills or segfaults that day.
The logs establish that server restarts interrupted the turns. They do not independently identify the initiator of each shutdown; the association with client close/reopen comes from my repeated experience and the matching SSH lifecycle code. This report concerns interrupted active turns, not confirmed loss of stored conversation history.
Probable cause
#9843, merged September 4 and included in stable v0.0.39 and v0.0.40, changed the SSH runner to execute the resolved T3 CLI directly instead of an npm/npx wrapper. The generated runner on the affected host contains this change.
That PR fixes an orphaned-process problem: previously the recorded PID could identify the npm wrapper, leaving the actual server alive after cleanup. The existing SSH finalizer now reaches the actual server, so closing the client can terminate the remote server and interrupt active provider turns. Fixing process ownership appears to have exposed a regression in the remote workflow.
At upstream 6c583620ff7ad3235b135af7107c0543467eecfa, SSH scope cleanup still calls stopRemoteServer(). This file is unchanged from v0.0.40. I do not have the prior working installation's exact version/logs, so #9843 is the probable trigger rather than a conclusively established version bisect.
Workaround
Installing T3 as an independent background service on the remote host worked:
npx t3@0.0.40 service install
I interrupted the two active turns before switching, installed the service, reconnected the desktop client to that existing server, and sent new messages to continue both threads. SSH now records the server as external, which exempts it from managed-server shutdown.
Verification after these steps on September 9, 2026 (UTC):
| Time |
Observation |
| 12:22:04 |
Independent t3code.service starts. |
| 12:25 |
Both threads resume running. |
| 12:48:06 |
A new desktop connection is recorded. The same running turns continue producing provider events through 12:56-12:57. |
Systemd reported zero service restarts, and neither affected thread emitted a provider error event between the service switch and the end of the inspection.
Before submitting
Area
apps/desktop (managed SSH lifecycle in packages/ssh, affecting the remote server and provider sessions)
Steps to reproduce
- Use T3 Code desktop v0.0.40 to connect to a Linux remote through the built-in managed SSH flow, allowing T3 to launch the remote server. Do not use an independently installed service for this reproduction.
- Start a long-running Codex turn on the remote environment.
- Fully quit the desktop client while the turn is running.
- Reopen the desktop client and reconnect to the same SSH environment.
- Inspect the thread and the remote server log.
Expected behavior
Remote agent work continues while the client is closed. Reconnecting shows the same running turn and current activity without requiring another prompt. Closing the client should not implicitly stop the remote environment's active work.
Actual behavior
The remote server restarts and active turns are marked failed. The client displays the restart error and requires another message to continue.
Impact
Major degradation or frequent failure. Long-running remote work is repeatedly interrupted when restarting the client.
Version or commit
Desktop and remote server: v0.0.40. Relevant behavior is still present on upstream main at 6c583620ff7ad3235b135af7107c0543467eecfa (checked September 9, 2026).
Environment
T3 Code desktop client using built-in SSH to a Linux remote; remote Node v24.16.0; Codex app-server, model gpt-6-astra. Client OS and exact Codex CLI version were not captured during this inspection.
Logs or stack traces
Selected remote ~/.t3/ssh-launch/<target-key>/server.log entries (timestamps converted to UTC):
[07:15:31.123] INFO (#270): Listening on http://127.0.0.1:3773
[10:10:52.189] INFO (#272): Listening on http://127.0.0.1:3773
[12:06:21.927] INFO (#272): Listening on http://127.0.0.1:3773
Corresponding persisted thread.session-set events (UTC, thread identifiers omitted):
Thread A 2026-09-09T10:10:52.314Z status=error
Thread A 2026-09-09T12:06:22.011Z status=error
Thread B 2026-09-09T07:15:31.179Z status=error
Thread B 2026-09-09T10:10:52.241Z status=error
Thread B 2026-09-09T12:06:21.969Z status=error
lastError: Provider session did not survive a server restart. Send a new message to continue.
Related: #2614 describes the orphaned-process problem addressed by #9843. This report is about the resulting interruption of active remote work when the client exits.
Restarting my T3 Code desktop client breaks running Codex threads on my remote machine connected through T3's managed SSH connection. When I reopen the client and reconnect, the threads show "Provider session did not survive a server restart. Send a new message to continue." Long-running agent work is interrupted and needs another message to continue. This previously worked for me: closing and reopening the client did not interrupt the remote work.
Observations
Read-only inspection of the remote server logs, persisted orchestration events, provider logs, and service state found the following on September 9, 2026. Times below are UTC:
The remote host had been up seven days. The kernel journal contained no OOM kills or segfaults that day.
The logs establish that server restarts interrupted the turns. They do not independently identify the initiator of each shutdown; the association with client close/reopen comes from my repeated experience and the matching SSH lifecycle code. This report concerns interrupted active turns, not confirmed loss of stored conversation history.
Probable cause
#9843, merged September 4 and included in stable v0.0.39 and v0.0.40, changed the SSH runner to execute the resolved T3 CLI directly instead of an npm/npx wrapper. The generated runner on the affected host contains this change.
That PR fixes an orphaned-process problem: previously the recorded PID could identify the npm wrapper, leaving the actual server alive after cleanup. The existing SSH finalizer now reaches the actual server, so closing the client can terminate the remote server and interrupt active provider turns. Fixing process ownership appears to have exposed a regression in the remote workflow.
At upstream
6c583620ff7ad3235b135af7107c0543467eecfa, SSH scope cleanup still callsstopRemoteServer(). This file is unchanged from v0.0.40. I do not have the prior working installation's exact version/logs, so #9843 is the probable trigger rather than a conclusively established version bisect.Workaround
Installing T3 as an independent background service on the remote host worked:
I interrupted the two active turns before switching, installed the service, reconnected the desktop client to that existing server, and sent new messages to continue both threads. SSH now records the server as
external, which exempts it from managed-server shutdown.Verification after these steps on September 9, 2026 (UTC):
t3code.servicestarts.Systemd reported zero service restarts, and neither affected thread emitted a provider error event between the service switch and the end of the inspection.
Before submitting
Area
apps/desktop (managed SSH lifecycle in
packages/ssh, affecting the remote server and provider sessions)Steps to reproduce
Expected behavior
Remote agent work continues while the client is closed. Reconnecting shows the same running turn and current activity without requiring another prompt. Closing the client should not implicitly stop the remote environment's active work.
Actual behavior
The remote server restarts and active turns are marked failed. The client displays the restart error and requires another message to continue.
Impact
Major degradation or frequent failure. Long-running remote work is repeatedly interrupted when restarting the client.
Version or commit
Desktop and remote server: v0.0.40. Relevant behavior is still present on upstream main at
6c583620ff7ad3235b135af7107c0543467eecfa(checked September 9, 2026).Environment
T3 Code desktop client using built-in SSH to a Linux remote; remote Node v24.16.0; Codex app-server, model
gpt-6-astra. Client OS and exact Codex CLI version were not captured during this inspection.Logs or stack traces
Selected remote
~/.t3/ssh-launch/<target-key>/server.logentries (timestamps converted to UTC):Corresponding persisted
thread.session-setevents (UTC, thread identifiers omitted):Related: #2614 describes the orphaned-process problem addressed by #9843. This report is about the resulting interruption of active remote work when the client exits.