Make project identity available when a remote SSH connection is established

What variant of Codex are you using?

App (Codex Desktop, macOS)

What feature would you like to see?

When Codex App opens an SSH connection for a remote project, nothing in that
connection indicates which project it is for. I would like some stable project
identity to be available at connection time.

What I observe

On macOS (App 26.818.61809), the App appears to open one SSH connection per host and
share it across every remote project on that host. The command it runs on the remote
side looks identical regardless of which project is being opened, and no
project-specific environment or argument is passed.

The practical consequence is that a host is the smallest unit Codex can distinguish.
Anything sitting between the client and the machine - a jump host, a bastion, a
ProxyCommand, or any SSH configuration keyed on the host being connected to - has
no way to tell one project from another.

Why I would like this

I work across several projects that live on different remote machines: different
toolchains, different resource sizes, and in some cases different network zones. What
I would like is a single entry in Codex called something like "Remote", and to have
opening a project connect to the machine that project belongs on.

Today the only way to express that is to create one SSH host entry per project. That
works, but it means the connection list grows with every project, every project shows
up in the "New project" host picker, and the mapping from project to machine lives in
~/.ssh/config rather than anywhere meaningful.

Behavior that would solve it - any one of these

1. Project-scoped connections - open or key the connection per project rather than
   per host, so a project's connection can be established independently.
2. A project identifier available to SSH - anything reaching the transport before
   meaningful traffic: an ssh -o SetEnv=... value, an extra argument, or a
   substitutable token usable in ProxyCommand, alongside OpenSSH's existing %n and
   %h. This is the smallest change and needs no new concepts - existing SSH
   configuration could then do the rest.
3. A per-project command or argument override on a connection.

Option 2 would be enough for me and I suspect for most people hitting this, since it
composes with standard OpenSSH configuration rather than requiring Codex to know
anything about the remote side.

Additional information

Observed on Codex App 26.818.61809 (macOS). The description above is from black-box
observation of the ssh processes the App spawns, not any claim about internals.

I noticed project/* methods already exist in the app-server protocol, so a project
concept may already be present at that layer; the gap is that it is not reflected when
the remote connection is established.

Happy to test pre-release builds.

Start by tracing the app-server protocol's existing project/* methods and the SSH connection setup observed from the App. Check how project context could reach the spawned SSH process, including arguments or environment, and verify the result across multiple projects on one host and through ProxyCommand or a bastion.