Canopy Remote, Claude Code, Copilot CLI, or SSH from your phone?

Start with the host and the task

Suppose a coding agent is repairing a checkout form while you leave your desk. The project also has a local API, a worker, a branch with a draft PR, and a second agent reviewing the change. First ask which process must stay alive: a Claude Code or Copilot CLI session, the Canopy desktop host, or an SSH-accessible machine and tmux session. A sleeping or powered-off host does not keep local execution going merely because a phone UI remains open. A lost phone connection also does not prove the host process stopped. Before sending another instruction, reconnect and inspect the same session, last prompt, checkout, and output.

Use the native CLI route when its conversation is the job

Claude Code Remote Control connects the Claude app or claude.ai/code to a local Claude process. Its docs now describe synchronized conversation, subagents, Git diff, model choice, and server mode with multiple sessions; it is not merely an approval button. The server can spawn sessions in one directory or separate worktrees, so verify its configured mode before assuming isolation. It requires an eligible claude.ai plan and login, not an API key, and some enterprise endpoints and policies disable it. Claude says local execution and filesystem access stay on the host, while the connected transcript is stored on Anthropic servers. If your whole task is inside Claude Code and its own mobile view shows the evidence you need, start there. It does not create a shared remote workspace for unrelated installed CLIs or your saved local server commands.

• Use `/remote-control` inside an existing Claude session or the documented CLI mode, then verify the named session on the phone.
• Check whether the session is interactive or server mode, which worktree it uses, and whether the host process is still running after a disconnect.
• Treat a remote Git diff as a review aid; compare it to the actual PR head and checks before merging.

Use Copilot CLI's remote surface for its own session

GitHub documents remote control for an interactive Copilot CLI session through GitHub.com or GitHub Mobile. It can answer questions, approve or deny permission requests and plans, send prompts, switch modes, and end the current operation; slash commands are not currently available there. GitHub says the same signed-in account alone can remotely control the session. Session messages, tool events, and permission requests go to GitHub, while shell commands and file operations still run locally. For organization or enterprise seats, the relevant policy must permit view and control; a GitHub-hosted repository is not required for the session itself. This is a good fit when the one Copilot CLI conversation is the work you need to steer. If a worker failed or another CLI owns the change, inspect those with the project tools that actually expose them.

• Confirm the session is interactive and the machine is online; scripted `--prompt` sessions are excluded in the current docs.
• After reconnecting, find the same session and compare the remote event with local Git and PR evidence.
• Do not assume a Copilot remote permission approval means the app's success and failure paths were tested.

Use Canopy Remote when the project has several moving parts

Canopy's current-main README describes an optional PIN-protected Remote browser surface for terminals, launching or resuming supported agents, files, changes, PRs, research, servers, instructions, tools, and usage. It can serve a LAN connection or a tunnel through a provider you choose. That makes sense when you need to see which of several installed CLI agents is waiting, whether the website/API/worker is running, and what branch or PR changed. Each CLI still owns its account, model, and native conversation; Canopy does not turn one provider subscription into team access. Remote is off by default, and anyone who can reach the endpoint and has the current PIN can drive its permitted surface. Verify the installed Canopy release because the main README can be ahead of the installer, and close or rotate the access window when finished.

• Before leaving, record the project, checkout, intended CLI session, local service, and expected stop point.
• On the phone, inspect terminal state, service logs, changed files, and PR before sending a second instruction.
• If the host app exits, check its process cleanup and use the CLI's own resume path; a closed phone tab is only the end of a view.

Use SSH and tmux when you need the shell itself

SSH gives an encrypted login to a reachable host; tmux lets terminal sessions survive a client disconnect while its server remains on that host. This route can be the most flexible for someone who already manages network access, terminal authentication, and shell commands. It also asks the operator to assemble the project view: which worktree, server URL, PR, model account, and test result belong to the task. An SSH connection alone is not a persistent agent process; place the agent inside a durable terminal session if you need detach and reattach, and verify its state after reconnecting. Avoid opening a general shell or broad network path when the narrower provider or Canopy surface supplies all the actions you need.

• Name the tmux session and record its project directory and branch.
• Check `git status --short --branch` and the process output after reattaching; a tmux pane can outlive the task it once showed.
• Use the host's normal access controls and network setup; a phone terminal is not the same as Canopy's project UI.

Run one phone trial before relying on it

On a disposable project, assign one small feature with a valid and failure check. Start the agent and app services from the desk, record the host, session, branch, and last prompt, then leave the local screen alone. From the phone, find the same task, answer one low-risk question, inspect a changed file or Git diff, and identify the running app and PR. Briefly disconnect the phone without stopping the host, reconnect, and check whether the earlier instruction was delivered before sending anything again. Finally, verify the accepted behavior, latest diff, tests, and PR state at the desktop. Record which facts the phone route could show directly and which required another tool. Choose the narrowest route that still lets you make a correct decision for your normal task.