Remote Control (RC) lets you use an agent on your own computer from the Hub in a desktop or mobile browser. The agent, project files, runtime login, and model configuration stay on that machine. The browser connects through the Hub; live conversation events and saved session history are sent to it.
A machine is a computer running the AgentGit daemon, agitd. A workspace
connects that machine to project folders and the people allowed to use them.
Registering a device is separate from a project’s local Agent repo binding.
1. Prepare the machine
Install AgentGit on the computer where your code lives. Install and sign in to at least one supported runtime there: Claude Code, Codex, or OpenCode. For example, check Codex from the terminal that will start the daemon:
agit --version
codex --version
agit login --hub https://agent-git.com
agit whoami --check
Use claude --version or opencode --version for those runtimes. Run a small
prompt in that runtime to verify its provider login. AgentGit login authorizes
the Hub connection; it does not sign in to your model provider.
2. Connect the device
With the published CLI 0.2.0, register the device and start its peer daemon:
agit rc cloud enroll --hub https://agent-git.com --name work-laptop
agit rc local start --detach
agit rc cloud status --hub https://agent-git.com
agit rc local status
Replace work-laptop with a recognizable name. Registration allows your signed-in
account to control this device; it does not open access to other users. --detach
runs the daemon in the background. Omit it to keep the daemon in the terminal.
For a different Hub, sign in with agit login --hub HUB_URL and use that same URL
for enrollment and the browser.
Open Workspaces and sign in with the same Hub account. Both registration and a running daemon are required for an online device.
In CLI 0.2.0, agit rc start and agit rc status address the older paired
connection. Its “connected” status does not mean the device is registered for the
current Web workspace. Use the commands above even if that status says connected.
Development builds with automatic enrollment use agit rc start --detach; check
your installed version before following development instructions.
Keep the machine awake, online, and the daemon running. Closing a browser tab does not stop a supervised agent. Stopping the daemon ends its running sessions.
3. Create a workspace and bind a folder
In Workspaces, create a workspace and check the machine named in the creation dialog. Open the workspace, then use Bind a folder to enter an absolute project path on that machine. The live view also offers + folder with a folder picker.
Binding a folder makes that project available within the workspace, subject to
workspace roles and the device’s resource policy. The Hub associates it with a private Agent repo, creating one when needed. Session
branches save conversation history there. Your project’s code repository stays
in its original folder; binding does not upload its .git repository.
The daemon checks project paths and routes approvals according to the workspace role. A folder binding is not an operating-system sandbox for arbitrary shell commands; review tool requests before authorizing them.
4. Start or continue a session
Open the workspace’s live view. Under Projects, choose the runtime button beside your bound folder to start a session. Send a prompt and read streamed replies, tool activity, and approval requests. Available controls depend on the machine’s runtime capability report.
To continue, select an existing session under its project. On this machine
also lists discovered local conversations. A conversation marked
live elsewhere · watch stays under its native runtime’s control. For Codex,
a current daemon and a Codex CLI supporting codex queue let the workspace owner
and full-access collaborators queue a message to that existing conversation.
The web composer says Queue; Codex picks the message up at a turn boundary.
A queued receipt confirms inbox submission, not that Codex has processed it.
Tool approvals, stopping the turn, and permission modes remain in the native app.
Other watched conversations remain read-only. Exit their native runtime before taking them over remotely. Do not start another writer against the same native conversation.
RC-supervised sessions save and attempt to push their turns at turn boundaries. The browser showing a reply does not establish that its commit reached the Hub: check the save status and any reported errors. Local pending commits are retained when a push fails. See saving and publishing for inspection and explicit recovery commands using the session’s repository and branch.
Renaming a session in the web UI changes its display title, not its branch name.
Collaborate and answer approvals
Under Shared with, the owner or any full-access collaborator can create an invitation link. Anyone holding the complete link can sign in, choose Join, and add their account to the workspace with the same workspace permissions as the owner. They can manage members and invitations, bind folders, use terminals, and answer owner-required approvals. Workspace repository ownership stays with the founding account.
Invitation links expire and can be revoked from the same panel. Revoking a link stops future joins; remove a collaborator from the member list to end their existing access. A removed collaborator cannot reuse an invitation they already redeemed to regain access.
You can also invite a Hub username and select a role:
| Role | What the person can do |
|---|---|
| Full access | Bind folders, manage members, use the machine’s file browser and terminal, and answer owner-required approvals |
| Operator | Start or drive sessions in bound projects and answer approvals that the daemon delegates to operators |
| Viewer | Read workspace sessions without sending prompts or approving tools |
Approvals marked as requiring the owner can be answered by the owner or a full-access collaborator. An operator cannot grant themselves broader permissions. Runtime permission modes are capability-dependent; controls that loosen protection are owner-only. Runtime support describes OpenCode’s single-request approval policy and limitations.
Workspace membership is also bounded by the device’s resource policy. Registering
the device automatically permits its owner; it does not authorize every workspace
member. A device owner can inspect agit rc cloud policy and use
agit rc cloud grant --help to grant a collaborator access to a specific project
or session. Use the collaborator’s immutable Hub account ID for that policy.
Stop or disable remote access
These commands apply to the published CLI 0.2.0 peer daemon:
| Command | Effect |
|---|---|
agit rc local status | Inspect the peer daemon and its live sessions |
agit rc cloud status --hub https://agent-git.com | Inspect device registration and inbound access |
agit rc cloud devices --hub https://agent-git.com | List devices available to your Hub account |
agit rc local stop | Stop the peer daemon and end its supervised sessions |
agit rc local start --detach | Start again with the saved device registration |
agit rc cloud inbound --hub https://agent-git.com --enabled false | Disable inbound Cloud connections |
agit rc cloud inbound --hub https://agent-git.com --enabled true | Enable inbound Cloud connections for the registered owner |
Disabling remote access keeps saved workspace and conversation records. The old
rc pair, rc list, and rc revoke commands manage paired connections; they do
not inspect or revoke the peer device used by the current workspace.
Troubleshooting
| Symptom | What to check |
|---|---|
| No machine appears | Check agit rc cloud status --hub https://agent-git.com and agit rc local status; the browser and CLI must use the same Hub and account |
| Machine is offline | Wake it, restore its network, and check the daemon; use a foreground start to inspect connection errors |
| Runtime is “Not found” | Install its executable on the daemon’s PATH, then stop and restart the daemon |
| Runtime is “Not reported” | Update AgentGit with agit upgrade, restart the daemon, and reload the live view |
| Runtime starts but cannot answer | Check that runtime’s provider configuration and login on the machine |
| Input is read-only | Check whether you are a viewer or watching a conversation active in another terminal |
| Tool is waiting for the owner | Ask the workspace owner to review the approval; reconnecting does not delegate it |
| Reply is visible but save failed | Read the save error, inspect the selected branch with agit log, and verify publication separately |
For a network that requires an HTTP CONNECT proxy, start the daemon with the proxy environment in that same shell:
HTTPS_PROXY=http://proxy.example.com:8888 agit rc local start --detach
Use your proxy’s address. Secure WebSockets use HTTPS_PROXY; ALL_PROXY is a
fallback and NO_PROXY can bypass selected hosts. Lowercase forms are also
supported, with uppercase taking precedence. The proxy URL must use http://;
HTTPS and SOCKS proxy URLs are not supported by the RC transport. TLS still
verifies the Hub certificate inside the tunnel. Restart the daemon after
changing its environment.