portal

# Portal Portal moves a local coding session to a paired computer while keeping the relay as the control plane and the paired computer as the execution residence. The Code Agents chat list supports moving one local chat or all eligible local and worktree chats in one handoff. ## Workflow 1. Select `Portal` for the coding session and keep the source folder as a Git repository with an `origin` remote. 2. Snapshot the current working tree, including dirty tracked and untracked code, into a unique `portal/<timestamp>-<id>` branch. Do not switch, reset, stash, or overwrite the source checkout. 3. Queue the run for a paired active host. The run metadata must identify the host, handoff id, branch, commit, and `envPolicy: "load-local"`. 4. On the paired host, fetch the exact commit into a detached Portal worktree under its local Agent-Native store. Preserve an existing dirty worktree and create a new one instead of overwriting it. 5. Load the paired host's current local environment files immediately before starting the runner. Never put environment values, tokens, or secrets in relay metadata, prompts, transcripts, or status messages. ## Existing chat transfer Use `Move to Portal` for one chat or `Move local chats to Portal` for the bulk handoff. The transfer stops a local runner before snapshotting, pushes the current worktree without changing the source checkout, and imports the full text transcript into the same run id on the paired computer. The target gets a continuation turn rather than replaying the original prompt. Chats waiting for local approval are skipped because approval state is computer-local and cannot be reconstructed safely. Binary attachment bodies are not relayed. Their names, text, and an explicit omission marker remain in the transcript context. Oversized or otherwise unsafe context fails visibly so the source chat can be retried instead of being silently truncated. ## Execution residence Treat `metadata.executionResidence` as authoritative for where the run is executing. It should report `kind: "portal"`, host id and label, handoff id, source commit, remote workspace path once prepared, and environment file names without values. Follow-ups and stops must target the same host and remote run. ## Verification Before saying Portal is ready, verify the relay has a paired host, the host is heartbeating, the exact handoff commit was fetched, the detached worktree is clean, and the run metadata reports the remote workspace. For an existing chat, also verify the target transcript contains the imported event count and the continuation turn. A queued command is not proof that the remote runner started; inspect the remote result or event readback. ## Operator recovery When a host is present but a handoff stalls: 1. Confirm the connector's `relayUrl` is the same deployment origin used for pairing. A device paired against another origin can return `401` with a fresh-looking token because the row is in a different database. 2. After repairing a pairing, restart the connector. It reads `remote-device.json` once at startup and will not adopt a new token or relay URL in an existing process. 3. Confirm the host is heartbeating and connected, then retry one bounded run. Read the remote result and transcript; enqueue success alone is not proof. 4. Keep tokens and environment values out of logs, prompts, metadata, and transcripts. Report source, published-runtime, and live-relay evidence separately. ## Don't - Do not copy `.env` contents or credentials to the source branch or relay. - Do not treat the primary laptop's cwd or environment as the remote cwd. - Do not report Portal complete from a local push alone; confirm remote execution residence and runner state. ## Related skills - `external-agents` - relay and external-agent boundaries. - `a2a-protocol` - idempotent cross-agent task lifecycle. - `concurrent-agents` - preserve shared checkouts and peer work. - `reliable-mutations` - verify durable handoff state.