Another Context Code from here

Your terminal can talk to the Context Code on another machine: the one at home from the office, the one on the server from your laptop. It’s exactly what the phone does when it scans the QR, but from a console.

The turn isn’t run by your machine: it’s queued over there, with the files and projects over there. You see what happens and decide what needs deciding.

Getting it going

# On the OTHER machine (the one with the agent and the projects):
contextcode serve --print-qr --public

# Here, with the URL it printed (it carries its ?t=…):
contextcode remoto agregar casa "https://algo.trycloudflare.com/?t=TOKEN"
contextcode remoto listar
contextcode remoto probar casa
contextcode chat --remoto casa

It also accepts the address and the token separately, or with no scheme:

contextcode remoto agregar vps 192.168.1.5:8787 --token TOKEN

What happens when you add it

1. /api/version is called, the only public route. It separates two problems that look alike and have opposite remedies: “I can’t reach that machine” and “I reach it, but the token isn’t valid”.
2. The credential is validated with a call that changes nothing.
3. The link token is exchanged for a device token. From then on, the QR token isn’t stored: keeping it would leave a live credential on your disk that would survive revocation.

The registry lives in ~/.context/remotos.json, with 0600 permissions where the system allows it. contextcode conexion tells you the exact path.

The two credentials

Credential	Where it comes from	How long it lasts	How it’s withdrawn
Link token	Generated by serve; it’s what goes inside the QR	From 1 minute to 30 days	By rotating it: they all fall at once
Device token	Requested once, presenting the link token	Doesn’t expire	One by one, without touching the others

The QR is the door, not the key. That’s why the link can be short-lived without forcing you to rescan every day, and why losing a phone doesn’t kick the others out.

The remote chat

contextcode chat --remoto casa                      # creates a new chat
contextcode chat --remoto casa --proyecto "Mi app"  # in that project (id or name)
contextcode chat --remoto casa --chat chat-a1b2     # continues an existing one
contextcode chat --remoto                           # the active remote

You’ll see the same as in a local chat — live text, tools, result — because they’re the same engine events, followed by polling the timeline on the other side.

Approvals are answered from your terminal

When the agent on the other machine asks permission to use a tool, the question shows up in your console ([s/N/siempre]) and your answer unblocks it. Without that, the turn would wait indefinitely for someone sitting in front of that machine — which is exactly what you’re avoiding.

If the network drops

The agent keeps working over there. The command tells you which line to use to get back in (--chat <id>) to pick up the answer when you return.

Note

In the remote chat you can’t send attachments yet.

remoto versus the desktop’s SSH workspaces

They don’t compete: they solve different cases.

	contextcode remoto	SSH workspace (desktop window)
Who uses it	The terminal, on any system	The desktop application
Transport	Direct HTTP against the serve	ssh -L and HTTP through the tunnel
Credential	QR token → device token	Your SSH keys
Needed on the server	contextcode serve already running	SSH access and the binary installed
Crosses the internet	Yes, with serve --public	Yes, if SSH is reachable

On your own VPS with SSH, the desktop uses the SSH workspace. To get there from a terminal — or from a machine where your keys aren’t — the way is remoto against serve --public.

SSH tunnels that no longer drop

If you used an SSH workspace and it cut out every so often, this was why: home NATs and some VPNs only count visible TCP traffic and recycle idle sessions, even though SSH is sending its own encrypted probes inside.

Now the connection carries keep-alive on both layers (ServerAliveInterval=15 with ServerAliveCountMax=3 in SSH, and TCPKeepAlive=yes in TCP). And if it still drops:

• The application detects the tunnel is dead and goes back to working locally on its own, instead of chaining three-second waits per command against a connection that no longer exists.
• Remote chats tolerate outages of more than two minutes, retrying with growing waits, before giving up.

When pairing fails

What you see	What’s going on and what to do
“Your computer rejected this link: it has expired”	The link expired or was regenerated. Generate a new one and scan again.
“Your access was revoked”	That device was revoked from the other side. Scan a new QR.
“Could not reach” and the PC is on	The local network QR points to an internal IP. Get on the same network, or ask for the tunnel QR with --public.
A VPS’s QR doesn’t work	Without --public, the link points to a data-center IP your phone can’t reach.
conexion says “the keychain didn’t return its token”	Server with no system keychain: use serve --token-file <path> to have a stable token.