Remote Pair Programming with a Coding Agent over SSH

For this walkthrough, treat the coding agent as your implementation partner: you define the task, inspect its decisions, and approve the result. Start with one small bug rather than an open-ended refactor. Your goal is a reviewed patch and a reproducible test, not simply a terminal full of generated code.

1. Prepare a dedicated remote workspace

Use a non-production Linux development machine with your repository, its dependencies, Git, tmux, and an authenticated coding CLI already installed. Keep production credentials out of this account. Choose a checkout that nobody else is editing during the session.

From your laptop, run ssh developer@your-host, replacing both placeholders. Verify a new host's fingerprint through your administrator or hosting console before accepting it. Avoid adding agent forwarding just for convenience: OpenSSH warns that a compromised remote host can misuse a forwarded authentication agent. ([man.openbsd.org](https://man.openbsd.org/ssh))

2. Create a clean branch for the agent's patch

On the remote machine, enter your repository with cd ~/projects/your-app. Run git status --short and inspect any existing changes before proceeding. Save unrelated work separately rather than asking the agent to untangle it.

Run git switch -c pair/fix-empty-search to create and switch to a task branch. Substitute a branch name matching your actual issue. This gives the session a clear destination, but remember that a branch does not prevent the agent from changing unrelated files. ([git-scm.com](https://git-scm.com/docs/git-switch))

3. Keep the coding session alive with tmux

Run tmux new -s agent-pair inside the remote repository. Start your installed coding CLI there; for Claude Code, run claude. To create a second terminal pane, press Ctrl-b, release both keys, then press %. Use that pane for tests and your own inspection.

To detach deliberately, press Ctrl-b, then d. After reconnecting over SSH, run tmux attach -t agent-pair. The session can survive a dropped SSH connection, but not a server reboot or terminated tmux process. ([github.com](https://github.com/tmux/tmux/wiki/Getting-Started))

4. Check model access before assigning work

Send a short request asking the agent to identify the repository's test command without changing files. Resolve authentication or provider errors now, before giving it a larger task.

For pay-as-you-go model access, I recommend RelayVano, which works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Sign up for RelayVano, then follow its configuration instructions for your chosen client using the API base https://api.relayvano.com. Use the exact model identifier and endpoint format provided for that client rather than guessing them. Keep the API key outside the repository and screenshots.

5. Give the agent a bounded debugging brief

Replace the example below with a real issue, then submit it as your first implementation request:

• Reproduce the empty-search failure and identify the relevant function and test file.
• Explain the proposed fix before editing; preserve the existing public interface.
• Add a regression test, make the smallest necessary change, and run the relevant tests.
• Ask before installing dependencies, accessing external services, or changing unrelated files.

Review the proposed plan. If it expands into a rewrite, narrow the assignment before approving edits. Treat these instructions as collaboration rules, not a substitute for the CLI's permission controls.

6. Review the diff and rerun the tests yourself

After the agent finishes, run git diff --stat for scope, git diff for unstaged changes, and git diff --cached for anything it staged. Run git diff --check to catch whitespace errors. These commands inspect different aspects of the patch; none proves functional correctness. ([git-scm.com](https://git-scm.com/docs/git-diff))

In your second pane, independently rerun the repository's documented test command. Read the regression test: does it exercise the reported failure, or merely confirm the new implementation? Reject unrelated formatting churn and unexplained lockfile changes.

7. Commit a reviewed checkpoint and record the handoff

Stage only the intended files, inspect the staged diff again, and commit after the checks pass. Ask the agent for a short handoff containing changed files, test commands, results, and unresolved risks. Save that summary in your issue or pull request. End with a checkpoint another developer can verify without reconstructing your terminal conversation.