Codex Desktop SSH task silently reattaches to local host, loses project binding, and cannot be handed back

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.72221 (build 5307)

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

I am encountering a recurring Codex Desktop state-corruption issue involving tasks running on an SSH remote host.

A task that was originally running successfully on my saved SSH remote project silently became attached to my local Mac. I did not initiate a handoff, change the task's run location, or select a local project. The task continued to retain the remote Linux working directory in its session metadata, but subsequent commands were actually executed locally.

The affected task was:

019f5d8f-d47b-7d10-954f-f1aee317e96c

Its expected environment was:

• SSH host: dev-env
• Remote project: /home/ubuntu/<project_name>
• Git repository: <project_name>

After the corruption occurred, Codex reported the task with hostId=local while still reporting its cwd as /home/ubuntu/<project name>. Because that Linux path does not exist on the Mac, commands began failing or executing in the wrong environment.

There was no recorded handoff event. The remote machine remained reachable, had not rebooted, and the Codex remote runtime was still available. Other newly created tasks could run successfully against the same saved remote project.

The task UI also stopped showing any run-location or host control in the footer, so there was no way to repair the binding through the interface.

I then attempted to hand the affected task back to dev-env from a separate Codex task. The handoff failed with this exact error:

The source thread workspace is not a git repository.

This failure appears to happen because the task is treated as local while its recorded workspace is still the remote Linux path. The handoff implementation validates that nonexistent path against the local filesystem before it can transfer the task back to the correct host.

Inspection of the local Codex state showed that the remote project was still saved correctly and dev-env was still the selected remote host. However, the affected task had no entry in .codex-global-state.json under thread-project-assignments.

The transcript also split into two copies. The remote transcript stopped receiving records, while the local transcript continued from that exact point. The remote transcript is an exact prefix of the newer local transcript:

• Remote transcript: 1,896 records
• Local transcript: 2,428 records
• SHA-256 of the complete remote transcript: 6842354d4cbfb5cb57f634288a7228206e6b60a23e7c350a541372448fe8b029
• SHA-256 of the first 1,896 records of the local transcript: 6842354d4cbfb5cb57f634288a7228206e6b60a23e7c350a541372448fe8b029

The remote transcript stopped at 2026-07-15T04:26:04.121Z. Incorrect local execution was confirmed later that day at approximately 17:59 UTC.

This is particularly concerning because the task can appear to retain its remote project context while commands are actually routed to a different host. That creates a risk of reading, modifying, or running code in the wrong repository or environment without a clear warning.

This has happened to me multiple times. This task is the instance for which I collected detailed state and transcript evidence.

What steps can reproduce the bug?

I do not yet have a fully deterministic minimal reproduction, but the failure has occurred multiple times with the following workflow:

1. Configure an SSH remote host in Codex Desktop.
2. Save a Git repository on that host as a remote project.
3. Create or continue a task in that remote project.
4. Verify that commands initially run on the remote host and that the working directory is the remote repository.
5. Leave the task idle and later reopen or resume it after the desktop app or SSH remote connection has reconnected.
6. Send another prompt to the existing task.
7. Observe that the task retains the remote Linux cwd, but its execution host has silently changed to local.
8. Observe that the task no longer exposes a run-location control in the footer.
9. From another task, attempt to hand the corrupted task back to the SSH host.
10. The handoff fails with The source thread workspace is not a git repository.

In the diagnosed occurrence, the original task's remote transcript stopped receiving events while an independent local copy continued. The local app state also lost the task's thread-project-assignments entry.

Creating a completely new task directly in the same saved SSH project worked correctly, which indicates that the SSH connection, remote repository, authentication, and saved-project configuration were healthy. The problem appears specific to restoration or rehydration of an existing task's host and project binding.

What is the expected behavior?

A task created on an SSH remote project should remain bound to that host and project unless I explicitly performs a handoff.

If the remote connection becomes unavailable, Codex should show the task as disconnected and require an explicit reconnect or handoff. It should never silently fall back to local execution while retaining a remote working directory or remote-project context.

When an existing task is reopened, Codex should reconcile and validate its thread ID, host ID, project assignment, working directory, and transcript location before allowing another command to run.

If those values disagree, the app should block execution and show a clear recovery action. It should also preserve the run-location control and allow the user to explicitly reattach the task to its saved remote project.

The handoff operation should be able to recover this state by accepting the explicitly selected destination project. It should not validate the stale remote Linux path against the incorrectly selected local host and then fail before the repair can occur.

Additional information

The session metadata on both machines already contained the expected remote working directory and Git repository information:

• cwd: /home/ubuntu/<project name> (remote)
• Git branch at session creation: main
• Codex runtime version recorded by the session: 0.144.1

The local app's saved remote-project configuration was also correct:

• Remote host ID: remote-ssh-discovered:dev-env
• Remote project path: /home/ubuntu/<project name>

The missing state was specifically the affected task's entry under thread-project-assignments.

A replacement task created directly in the same saved remote project immediately reported the correct remote host and working directory, further indicating that this was not an SSH-connectivity or repository problem.

Replacement task ID:

019f674a-ff1c-78d0-8d1c-cb5af061c9d6

Potentially related reports include:

• https://github.com/openai/codex/issues/25250
• https://github.com/openai/codex/issues/20399

However, this occurrence is distinct in that I have one SSH remote host, the affected existing task silently switched from that remote host to the local Mac, and no explicit handoff occurred.

I have not attached the complete JSONL transcripts because they contain private conversation and repository context. I can provide sanitized excerpts, state-file sections, timestamps, hashes, or logs privately if requested.