Several sessions, one Mac

Open as many Ocean Code windows on a project as you like: one on the backend, one on the tests, one writing the release note. Every engine on the Mac shares one small file, peers.db, and through it the sessions know about each other. Nothing about another session ever enters a prompt; the model hears about one only when it is about to touch that session's file, or when you accept a request.

See

Every session has a code, the last four characters of its id: #2oca. The status bar shows it on the right, the terminal tab starts with it (#2oca Fix login), and oceancode status 2oca, /status 2oca and the agent's sessions tool find a session by it.

The chip. When other sessions run on the machine, the status bar shows ⇄N OC <state>: N other Ocean Code sessions, and what they do. It turns every four seconds between this window's own state (idle, busy, blocked) and the others' (1 working, 2 waiting, writing here). Green means nothing is wrong, yellow that another session waits for its user, amber that another session writes under this folder, red that this session is blocked by another one's claim. Click it for the list: one entry per session with its code, state, title, folder, the running tool and the files it writes.

The board. /status in the pager, or oceancode status from any shell, prints every Ocean Code session on the machine, the ones waiting for you first:

Ocean Code sessions · 2 · 1 working, 1 empty
#2oca  working         AI consulting v3  3/9  4m
       now: Task 16: round-2 re-review running
       next: Task 16 fix round 2 · 1 helper · holds 2 files · est. ~40m–1.5h (rough) · pid 45683
#f2k1  empty           New session  12m
       pid 51022

Each session carries one state (waiting for you, blocked, stuck? when its plan has not moved for 30 minutes, working, idle, empty, done, crashed, closed), its plan progress, the row it is on and the next one, its helpers, the files it holds and, once three rows are done, a rough time estimate from its pace so far. oceancode status all adds closed sessions; oceancode status <code | words> finds one. A window you opened but never typed into reads empty.

Stay out of each other's way

A session holds the files it edits until its turn ends. write, edit and apply_patch claim the file automatically; a sub-agent writes under its root session's claims, and a background sub-agent's claims last until it finishes. Nothing needs to be set up.

Another session that tries to write a held file is refused before anything is written, and told who has it:

runner.rs is being written by session "wake-visible" (4 min, "turns fix");
work on something else or try again later

apply_patch checks every file of a patch first, so a refusal leaves the tree as it was. A crashed session blocks nobody for more than 15 seconds: its claims clear with its heartbeat.

For work that is not one file, the agent's claim tool holds a path or a name (name:consulting-regress) for up to 60 minutes, past the end of its turn, which also covers what a script writes inside bash. Your override is /peers take <path | name:label>: the claim moves to your session. /peers prints the other sessions with their claims, and oceancode peers log prints a week of who blocked, took or released what.

Ask

When an agent finds work that is not its own, a bug in a file another session is writing, it does not start editing. It sends that session a short request with the ask_session tool. Ocean Code routes it to the session holding a claim on the files named; otherwise to an empty Ocean Code window open in the same project; otherwise it waits for the next empty window you open there. A session that has finished its work never takes another session's new work.

The request prints in the receiving window, with a toast:

Request r12 from #2oca "frontend" — you hold db/schema.sql
  users.email has no unique index (db/schema.sql:41)
  /peers accept r12  ·  /peers decline r12

You decide. /peers accept r12 queues the request as that session's next prompt, like a typed one; /peers decline r12 declines it. The asking agent is told where its request went and carries on; it never receives an answer, and its text reaches a model only as the prompt a user accepted. The asking window sees r12 accepted in #f2k1, then r12 done in #f2k1 when the turn that ran it finishes, stopped when that turn was cancelled or failed, or declined / expired. Deleting the queued prompt before it runs withdraws the request.

Limits keep it quiet: at most three open requests per session, one between the same two sessions, an hour before an open request expires. The full rules are in the permissions reference.

Resume

From anywhere. oceancode resume 2oca, or oceancode resume "consulting v3" with words from the title, opens any session on the Mac in its own folder, wherever it ran. If the session is open in another window, the command names that window instead.

Where it left off. Opening a session with open plan rows, or whose last turn was still running when its window closed or crashed, prints a resume card under the transcript:

Where #2oca left off — "AI consulting v3"
Last active 14:05 (12m ago) · plan 3/9 · ended: crashed
  now:  Task 16: round-2 re-review running
  next: Task 16 fix round 2
  interrupted: bash `bash x3-steps.sh` (14:03)
Type /continue to carry on from here.

/continue sends the prompt that carries on: the plan's next open rows and, when something was cut off, the list of interrupted calls to check before repeating them. A tool call that was interrupted reads as interrupted in the replay, never as completed. A finished session shows no card.

Titles you can find. A session is named from what you typed, never from a skill or a command's expansion, so /unlazy fix the dock is titled "fix the dock".

Away from the Mac

The same sessions reach you in Slack when they wait, finish or are blocked, and a Notification hook fires the same events into anything else: Away from the Mac.

Next

• CLI reference: oceancode status, oceancode resume, oceancode peers.
• Ocean pager reference: /status, /peers, /continue.