A remote coding agent may need to read a repository, install dependencies, or push a branch. The moment it runs on another machine, one credential question matters: should that host borrow your laptop's SSH agent, or should it have its own narrowly scoped key?
The quick option is agent forwarding. It lets a remote host ask your local SSH agent to authenticate to another service, such as GitHub, without copying your private key onto the remote machine. The safer default for a persistent agent host is usually a separate credential with only the access that host needs.
These choices are easy to confuse because both can make git fetch work. They create different trust boundaries, though. Here is how to choose, including a practical setup for a remote AI coding environment.
A remote coding workflow can involve two links:
The first connection gets the agent onto the development host. The second gives a process on that host repository access. Your credentials for the first link do not automatically need to grant broad access on the second.
OpenAI's current Remote SSH instructions illustrate this split. The desktop app discovers an SSH host from ~/.ssh/config, starts the remote Codex app server through SSH, and expects Codex to be installed and authenticated on the remote host. The docs show a host-specific IdentityFile; they do not say to enable agent forwarding for every connection. (OpenAI Remote connections)
That is a useful design principle beyond one product: connect the tool to the machine where work belongs, then decide separately how that machine should access source control.
An SSH agent holds keys and can perform authentication operations for SSH clients. With agent forwarding enabled, the remote host gets access to a forwarded socket that can ask your local agent to use loaded identities. The private key itself is not copied to the remote machine.
For a short-lived session on a machine you trust, this can be convenient. You use your normal GitHub identity, and the remote host can fetch private repositories without storing another private key.
The important limitation is that "the key is not copied" does not mean "the remote host cannot use it." OpenSSH warns that users able to access the forwarded socket can perform authentication operations with identities loaded in your agent. They do not need to extract the private key to authenticate as you while the forwarding path is available. (OpenBSD ssh_config manual)
This is why forwarding an agent to an unknown or shared host is a poor trade. A compromised process or account on that host may be able to use the forwarded identity to reach other systems during the session.
If forwarding is genuinely needed, scope it to one trusted host rather than enabling it globally:
Host trusted-buildbox
HostName buildbox.example.net
User dev
IdentityFile ~/.ssh/id_ed25519
ForwardAgent yes
Do not put ForwardAgent yes under Host *. OpenSSH's default is no, and its manual explicitly says forwarding should be enabled with caution. (OpenBSD ssh_config manual)
Also remember that the remote server must permit agent forwarding, and your local agent must be running. GitHub's documentation describes these requirements and how to test whether a forwarded agent is available. (GitHub: Using SSH agent forwarding)
A separate key makes the remote host's access independent of the laptop's agent. You can create a key for one machine or one repository, then revoke it without changing your personal laptop setup.
For a server that only needs to fetch one repository, a GitHub deploy key is one option. GitHub says deploy keys are read-only by default and apply to a single repository. You can enable write access, but that raises the impact if the server is compromised. GitHub also notes that deploy keys do not expire automatically and are usually not protected by a passphrase, so they require a revocation and rotation plan. (GitHub: Managing deploy keys)
A key stored on the remote host is still a secret. Anyone who compromises that host may be able to use it. The benefit is not magic protection; it is narrower and more predictable access. A read-only key for one repository cannot push to every repository available to your personal account.
For more complex automation, GitHub recommends considering a GitHub App for more fine-grained permissions. Installation access tokens can be limited to selected repositories and permissions, and are short-lived. That takes more setup, but it avoids a permanent personal key sitting on a long-running machine. (GitHub: Managing deploy keys)
Use the machine's role and lifetime to decide:
This is not a claim that deploy keys are always safer. A long-lived write-enabled key on a persistent server can be worse than carefully scoped forwarding for a temporary session. Compare how much access the credential grants, where it lives, how long it remains useful, and how quickly you can revoke it.
1. Make the host connection explicit. Use a host alias and a dedicated key for laptop-to-host access. OpenAI's setup guide documents this format for remote projects:
Host agent-devbox
HostName devbox.example.net
User dev
IdentityFile ~/.ssh/agent-devbox_ed25519
IdentitiesOnly yes
Check that ordinary SSH works before configuring the desktop tool:
ssh agent-devbox
OpenAI's guide says the app uses the SSH host configuration to discover hosts, starts its remote app server through SSH, and requires the remote command to be available in the remote user's login-shell PATH. Follow the product's current setup guide for installation and authentication steps. (OpenAI Remote connections)
2. Keep forwarding off unless a real workflow needs it. ForwardAgent defaults to no. If a task needs a second SSH connection, first ask whether that connection can use a repository-specific credential instead. If forwarding is the right fit, enable it only for the trusted host alias and remove it when the need ends.
3. Scope the remote Git credential. For a host that only clones or fetches one repository, consider a read-only deploy key. If the agent must push, prefer the narrowest supported write permission and repository scope. For access across repositories, compare a GitHub App with a permanent personal key.
4. Check where credentials can be used. Identify which user account runs the agent, which files and sockets it can read, whether it has SSH_AUTH_SOCK, and what repository permissions it has. Avoid running the agent as a privileged account or sharing the host with unrelated users.
5. Write down revocation steps. Know how to remove the deploy key or revoke the app installation, terminate active sessions, and rotate any credentials stored on the host. A credential without a clear owner and removal path becomes forgotten infrastructure.
Save this before connecting an agent to a remote host:
If the answers are unclear, start without forwarding. Add access only when the task demonstrates a need for it.
Agent forwarding avoids copying a private key, but gives the remote host a path to use the identities loaded in your local agent. A dedicated remote credential puts the secret on the remote host, but can be scoped to a particular repository and permission level. Neither option removes risk; the right choice depends on the trustworthiness of the host, credential scope, duration, and revocation plan.
For a long-running AI coding host, separate and limited credentials are usually easier to reason about than forwarding a broad personal agent. For a trusted, temporary session, narrowly scoped forwarding may be acceptable. Treat both as access decisions, not convenience toggles.
If practical security guides for developer tools are useful, subscribe for more. How do you handle Git access from remote coding agents: agent forwarding, deploy keys, or short-lived app credentials?