codex - 💡(How to fix) Fix Support multi-host SSH workflows within a single Codex conversation

Summary

Codex supports working with local projects and SSH remote projects, but each conversation appears to be bound to a single active context: local, SSH host A, or SSH host B.

For many real-world infrastructure and development workflows, a task may need to inspect, compare, edit, or coordinate work across multiple SSH hosts in the same conversation. It would be valuable for Codex to support multi-host SSH workflows where one task can move between approved hosts safely and explicitly.

Problem

When a conversation is tied to only one host, multi-server work becomes fragmented. The user may need to open separate chats for each server, manually copy findings between them, and coordinate state outside Codex.

This is limiting for tasks such as:

1. Auditing the same service across staging and production servers.
2. Comparing configuration, logs, environment variables, or deployed versions across hosts.
3. Applying a coordinated fix that requires checking one server, editing another, and validating on a third.
4. Investigating incidents where the relevant evidence is spread across multiple machines.
5. Running long-running diagnostics where each host has a different role in the system.

In these cases, the natural workflow is not one isolated chat per host. The natural workflow is one conversation with clear, controlled access to multiple approved SSH targets.

Feature request

Add support for a single Codex conversation, task, or goal to access multiple approved SSH hosts, with explicit host selection and host-aware command approval.

Suggested design

• Allow a conversation to include more than one SSH host when the user explicitly grants access.
• Show all active hosts attached to the conversation.
• Let Codex switch between hosts during a task when needed.
• Clearly display the target host before every command, file edit, diff, or approval.
• Support host-aware working directories, shells, environment assumptions, and permissions.
• Let users restrict a task to read-only access on some hosts and write access on others.
• Preserve separate credentials and SSH configuration per host.
• Allow multi-host plans, where Codex can say which host it needs to inspect or modify next.
• Support mobile follow-up and approvals for multi-host workflows when mobile control is available.

Safety and UX safeguards

• Every command approval should show the exact target host and path.
• Codex should not silently switch hosts without making the active context visible.
• Destructive commands should require especially clear host labeling.
• The UI should make it obvious whether the current step is local, host A, host B, or another registered environment.
• Users should be able to detach a host from the conversation at any time.
• Audit logs should record which host each command or file change targeted.

Relationship to other requests

This complements related requests around mobile control, headless remote hosts, scoped agents, and goal workflows, but it is a separate capability.

The main request here is multi-host orchestration inside one Codex conversation, rather than one conversation being permanently tied to only one local or SSH context.

Related issues:

• #23082
• #23200
• #23201
• #23202

Expected benefit

This would make Codex much more useful for server administration, DevOps, incident response, distributed systems debugging, migrations, and any workflow where the relevant files, logs, and commands live across multiple SSH-accessible machines.

Suggested labels, if available: enhancement, ssh, remote, multi-host, devops, app

Redaction check

This request intentionally uses only generic examples. It does not include real hostnames, IP addresses, usernames, private repository names, company names, credentials, tokens, or internal paths.