Agent sessions

Offsite does not implement an agent. It starts the CLI you already have installed, in a tmux session on the host, and streams it to your devices.

That means your ~/.claude, your AGENTS.md, your MCP servers, your skills, your hooks and your subscription all apply exactly as they do in your own terminal. Nothing is proxied and no token passes through Offsite.

Permission mode

You pick it when starting a session, and it maps onto each CLI’s native flags:

Mode	Meaning	What it does
Auto (default)	Works in the workspace, asks only for risky actions	the CLI’s own automatic approval mode: edits and commands inside the workspace run without a prompt; network access, writes outside the workspace and destructive commands still ask
YOLO	Maximum permissions for unattended work	approvals and sandbox bypassed

Both modes are built for a session that runs while you are elsewhere: Auto keeps the agent inside the workspace, YOLO takes the brakes off. Codex dropped its own prompt-on-everything mode (--ask-for-approval untrusted) in 0.149 for the same reason.

YOLO is what makes overnight work possible, and it is exactly as dangerous as it sounds — the agent can run anything in that workspace without asking. Use it where the blast radius is bounded, and prefer a host user that is not root.

YOLO for this start lets you take a session into YOLO once without making it the session’s permanent mode.

Caution

Claude Code refuses to bypass permissions when running as root. If YOLO is greyed out or the session refuses to start in it, check which user your host runs as. See A second Mac as a host.

Model and effort

A session can pin a model and, where the CLI supports it, an effort level. Both are optional; left empty, the CLI’s own default applies.

Both are re-applied when a session is restored after a reboot, so a resumed conversation keeps the configuration it was started with.

Naming sessions

You rarely have to. Every agent session names its own card in its first response and keeps a one-line recap current after that, so a board full of agents stays readable and a notification says which agent is waiting. Rename a card yourself and your name is final — see Cards that name themselves.

Several agents at once

Different providers side by side is a normal way to work here: Claude for the refactor, Codex for the tests, Grok for the odd bug. They are separate cards in one workspace, each in its native CLI, each with its own permission mode.

Offsite and the CLI’s own session commands

A card is a window onto one native conversation, and the CLIs have their own ways of changing which conversation that is: /resume, /clear, /new, /fork, /cd in Claude Code and Codex, plus /archive and /delete in Codex. You can use all of them. Offsite follows the change instead of fighting it: the card keeps tracking the conversation it actually shows, so notifications, the resume archive and a restore after a reboot all refer to the right one.

When that happens, the card gets a small chip in its chrome; tap it for the details (origin, old and new ID).

Chip	What happened	Anything to do?
Resumed	The conversation continues under a new native session ID — /resume, /clear, /new, /fork.	No. Everything keeps working.
Other workspace	The conversation moved to a different directory (/cd). The card stays on its workspace, so the Git and Files cards next to it no longer match what the agent works on.	Fine for a quick detour. For real work in the other repo, start a card on that workspace.
New thread	You archived or deleted the previous conversation in the CLI (/archive, /delete) and the card was restored afterwards. Offsite honours that and starts fresh instead of resurrecting it.	No. Offsite’s own safety copy is removed on /delete too.
Broken	The pane shows another session’s conversation, or the conversation moved into the CLI’s background daemon.	The session works, but parts of Offsite’s functionality may be limited. The chip offers the command that returns the pane to its own conversation.

A few things that follow from this:

• Restore resumes what you last saw. After /new or /cd, a reboot restore brings back that conversation, in its own directory.
• /permissions in Codex sticks. Changing the permission profile inside the Codex TUI updates the card’s permission mode, so the next restore relaunches with the profile you chose.
• Questions reach you. A Codex plan-mode question (request_user_input) shows up as “needs your input” with its options, like Claude’s.
• Subagents stay quiet. A Codex subagent finishing its task is not your turn ending; the card waits for the root agent.
• codex agents does not see Offsite sessions, and /agents inside a card reports that the session is not connected to a shared background server. That is intended: the board is the session model; Codex’s shared daemon would let sessions be opened, renamed and stopped behind the cards’ back.

Details

The exact flags Offsite passes, per tool and mode:

Mode	Claude	Codex	Grok
Auto	--permission-mode auto	--ask-for-approval on-request --sandbox workspace-write	--permission-mode auto
YOLO	--permission-mode bypassPermissions	--dangerously-bypass-approvals-and-sandbox	--permission-mode bypassPermissions

• Claude and Grok sessions are started with an explicit --session-id so Offsite can later --resume exactly that conversation. Codex resumes through its own thread discovery.
• Offsite injects a --settings block for Claude containing only hook commands that report session lifecycle events back to the host (SessionStart, UserPromptSubmit, Stop, permission-prompt Notification, and PreToolUse for question/plan tools). Those hooks are what make notifications deterministic instead of screen-scraped.
• Offsite also appends a short system-prompt block describing the Offsite environment, so an agent knows it may be driven from a phone and should not open GUI dialogs on the host’s screen.
• CLAUDE_CODE_NO_FLICKER=1 is set on Claude sessions. It keeps the CLI in its fullscreen renderer, which is what the card is built to display.
• Grok sessions get their own GROK_HOME per session.