codex - 💡(How to fix) Fix Goal mode fails ambiguously in Windows-to-SSH sessions with local attachments

Summary

In a Windows-to-SSH Codex session, enabling Pursue Goal / Buscar meta with a prompt plus a local Windows-side attachment can show the toast:

Failed to set goal

However, the session may still start anyway. From the user's point of view this is ambiguous: it is not clear whether the goal was set, whether the goal failed but the prompt continued as a normal turn, or whether the attachment/prompt was partially interpreted.

In practice, the session appears to continue as a normal SSH session with the prompt and attached .md file, but without a durable active goal.

Environment

• Product surface: Codex App / IDE extension goal UI
• Local workstation: Windows
• Workspace mode: SSH remote project on Linux
• Remote Codex CLI observed in the SSH environment: codex-cli 0.134.0
• Remote OS observed: Linux 5.15.0-173-generic x86_64
• Typical attachment: local Windows .md file attached to the composer
• UI action: enable Buscar meta / Pursue Goal, then submit a prompt with the attachment

Reproduction A: new SSH session with attachment and Goal enabled

1. On Windows, open Codex and connect to a Linux SSH remote project.
2. Attach a local Windows-side .md file in the composer.
3. Enable Buscar meta / Pursue Goal.
4. Type a prompt that depends on the attached file.
5. Submit.
6. Observe the UI toast:

Failed to set goal

1. Despite the failure toast, the session still starts and the agent receives the prompt/attachment in the SSH session.
2. The UI/user cannot tell whether the goal is active. Observed behavior suggests the turn is running without the durable goal state.

Reproduction B: existing SSH session, later prompt with Goal enabled

1. Start a normal SSH session without Goal enabled.
2. Continue for several back-and-forth prompts.
3. Later, enable Buscar meta / Pursue Goal for a new prompt.
4. Try to send that prompt.
5. The UI again shows the same Failed to set goal popup, and in this case the message is not allowed to send while that option is enabled.

Expected behavior

The goal path should be atomic and explicit.

If the goal can be set:

• persist the goal successfully;
• show a reliable active goal state/chip;
• start the SSH turn with that goal attached to the thread lifecycle.

If the goal cannot be set:

• do not silently or ambiguously start a normal turn;
• preserve the user's prompt and attachments;
• show an actionable error that names the failing boundary, for example local attachment materialization, Windows-to-SSH attachment forwarding, goal validation, or backend persistence;
• if Codex intentionally continues without a goal, the UI should say so explicitly: Goal was not set; continuing as a normal turn.

Actual behavior

• A generic Failed to set goal toast appears.
• In one flow, the turn/session still starts anyway.
• In another flow, a later message in an existing SSH session cannot be sent with Goal enabled.
• The user has no reliable way to know whether Goal mode is active or whether the attached .md was considered when computing the goal objective.

Local/remote evidence

On the remote SSH side, after inspecting the current environment on 2026-05-31:

codex-cli 0.134.0
remote OS: Linux 5.15.0-173-generic x86_64
remote ~/.codex/state_5.sqlite thread_goals row count: 0
current remote thread source: vscode
current remote cwd pattern: /root

This does not by itself prove the Windows host-side failure path, because the attachment starts on Windows and goal state may be managed across the app/remote boundary. It does support the observed user experience that the remote session continues without an inspectable persisted goal on the remote side.

Why this is not the same as the existing attachment issue

Related but not a strict duplicate: #25346 covers Codex Desktop /goal ignoring auto-created Pasted text.txt attachments and treating the goal objective as empty.

This report is specifically about the Windows-to-SSH boundary and the ambiguous partial-success behavior:

• local Windows attachment plus SSH remote execution context;
• generic Failed to set goal toast;
• sometimes the turn starts anyway without clear goal state;
• sometimes a later SSH-session message cannot be sent with Goal enabled.

It may share an underlying cause with attachment materialization, but the SSH/local-file boundary and the inconsistent send/start behavior need their own regression coverage.

Suggested fix

• Materialize the exact goal objective before calling the goal-set path, including any supported text attachments.
• Treat local-file attachments in SSH sessions explicitly: either forward/materialize them for goal validation or reject them with a targeted unsupported-attachment message.
• Make thread/goal/set failure either block the turn cleanly or continue only with an explicit "normal turn, no goal" state.
• Ensure the active goal state is visible and consistent across the Windows host UI and remote SSH execution context.
• Add regression tests for Windows host + SSH remote + .md attachment + Pursue Goal enabled.