Missing key at ["thread"]["sessionId"]

The Codex provider fails over SSH with a missing sessionId in the thread/start response. Restarting the remote t3 serve process usually clears it.

Last reviewed 2026-07-27 · verified against the pingdotgg/t3code repo

Missing key at ["thread"]["sessionId"] in thread/start response

Seen when using the Codex provider on a remote host over SSH. The provider adapter rejects the app-server's thread/start response because the sessionId it expects isn't there.

Try this first#

Restart the remote t3 serve process. This is reported to get past the failure.

# on the remote machine
pkill -f "t3 serve"
npx t3 serve --host "$(tailscale ip -4)"

A stale server holding a provider subprocess in a bad state is the usual explanation, and restarting gives you a clean handshake.

If it comes back#

1. Update Codex on the remote machine#

This is a response-shape mismatch between what the adapter expects and what app-server returns — which is the signature of version skew. Update the CLI on the remote host, not your laptop:

ssh user@remote
npm i -g @openai/codex@latest
codex --version

It's easy to update the wrong machine here. The provider runs where the server runs.

2. Update T3 Code on the remote machine#

The skew can be either direction:

# on the remote host
npx t3@latest serve --host "$(tailscale ip -4)"

Keep versions aligned across both machines while you're debugging — a remote on one build and a local desktop app on another adds a variable you don't need.

3. Confirm Codex works standalone there#

ssh user@remote
codex login
codex --version

If Codex can't start a session on the remote host by itself, that's the actual problem.

4. Check the remote Node version#

Remote environments require:

^22.16 || ^23.11 || >=24.10

ssh user@remote 'node --version'

An incompatible Node produces a range of odd provider failures rather than one clear message.

5. Check the non-interactive PATH#

ssh user@remote 'echo $PATH'
ssh user@remote 'which codex'

If codex isn't on the non-interactive PATH, the server may be resolving a different binary than you expect — possibly an old one. T3 Code searches Volta, asdf, mise, fnm, nodenv and nvm for remote environments, but a custom location needs to be on that PATH. PATH details →

6. Clear stale processes on the remote host#

ssh user@remote
ps aux | grep -E "codex|t3"
kill -9 <pid>

Things that don't cause this#

Worth ruling out so you don't chase them:

• Network quality. This is a response-shape error, not a transport error. A flaky link produces disconnects, not a missing key.
• Your local machine. Everything relevant runs on the remote host.
• Pairing tokens. An auth failure looks like an auth failure, not this.

Reducing remote friction generally#

• Keep versions aligned. Same T3 Code build and same provider CLI version on both ends.
• Restart the server after updating anything on the remote host.
• Prefer a stable transport. Tailscale or an SSH tunnel over an ad-hoc LAN binding.
• Don't let the host sleep. A suspended machine kills sessions mid-run.

Remote access guide →

FAQ#

What causes the missing sessionId error in T3 Code?#

The Codex provider adapter rejects the app-server's thread/start response because the expected sessionId field is absent, typically a version mismatch between T3 Code and the Codex CLI on the remote host.

How do I fix the T3 Code remote SSH sessionId error?#

Restart the remote t3 serve process first, which is reported to clear it. If it recurs, update the Codex CLI and T3 Code on the remote machine and confirm Codex works there standalone.

Which machine do I update, local or remote?#

The remote one. The provider CLI runs wherever the T3 Code server runs, so that's where version skew matters.

What Node version do remote T3 Code environments need?#

^22.16 || ^23.11 || >=24.10. An incompatible version causes assorted provider startup failures.