Why terminals duplicate,
and how we stop it

Plain English, no code. Two bugs, two fixes, then one decision for you.

The whole design in one line:
Keep our own notes about which terminal is whose — and never guess whether a program died.
Setup

What's behind one terminal

When you open a terminal on a remote machine, there are three things, not one.

The three pieces⤢ zoom

THE PANE
the box on your screen

THE NOTE
this pane goes
with that program

THE PROGRAM
really running on
the other machine

THE PANE
the box on your screen

THE NOTE
this pane goes
with that program

THE PROGRAM
really running on
the other machine

Your network blips. The pane stays on screen. The program keeps running over there. Only the connection between them breaks.

So reconnecting is one job: match the notes back up to the programs. Both bugs below are that matching going wrong.

Bug one

The notes piled up

A real user report: 2 terminals became 19, then 20. Most were panes they never opened.

Why they multiplied⤢ zoom

you have 2 terminals

blip → reconnect

Orca writes a new note
and keeps the old one

another blip

another note.
old ones still kept.

reconnect restores EVERY note.
one pane per note.
19 panes

you have 2 terminals

blip → reconnect

Orca writes a new note
and keeps the old one

another blip

another note.
old ones still kept.

reconnect restores EVERY note.
one pane per note.
19 panes

The cause is boring and completely fixable: the notes were filed under the program's name, not the pane's. One pane could collect unlimited notes, and nothing threw the old ones away.

The fix: one slot per pane

Filed by pane instead⤢ zoom

after · filed by pane

pane A

its one note

before · filed by program

pane A

note 1

note 2

note 3

after · filed by pane

pane A

its one note

before · filed by program

pane A

note 1

note 2

note 3

Piling up is no longer something we prevent — there is one slot, so it cannot happen. That's the difference between a rule you enforce and a shape where the bug has nowhere to live.

One detail that matters

The note is filed under a permanent serial number stamped on the pane when it's created — not under "which tab it's in". Tabs change: you can drag a pane into another tab any time. A serial number never does. File things under what doesn't move.

Bug two

"I can't find it" was read as "it died"

This is the worse one, because it's how you end up with two AI agents writing into the same conversation.

Drag a pane to a new tab, then reconnect⤢ zoom

you drag a pane
into a new tab

the other machine still has
the OLD tab written down

on reconnect it compares, sees
a difference, and replies:
no such terminal

Orca reads that as
the program died

starts a replacement,
and resumes your agent again

TWO agents writing to one
conversation. the first one
never stopped.

you drag a pane
into a new tab

the other machine still has
the OLD tab written down

on reconnect it compares, sees
a difference, and replies:
no such terminal

Orca reads that as
the program died

starts a replacement,
and resumes your agent again

TWO agents writing to one
conversation. the first one
never stopped.

The trick in it

The other machine did find your program. Comparing is how it noticed the tab was different. But it answered "not found" — so a message meaning "it's alive and I'm being fussy" looked exactly like "it's gone."

Fix, part one: stop comparing tabs

Moving a pane between tabs is a normal thing you're allowed to do, so it must never make a terminal unreachable. That comparison is removed.

It was also failing at its real job anyway. It existed to catch a different problem — the remote machine reusing an old ID for a brand-new program, like an apartment number being handed to a new tenant. It never caught that. So we check the tenant instead of the apartment number: catches the real case, stops rejecting panes that merely moved.

Fix, part two: never guess about death

A replacement terminal starts only on actual proof the old program is gone.

What counts as proof⤢ zoom

did the program die?

we watched it exit

the same helper that started it
says it's gone

can't reach the machine

it timed out

missing from a list

confusing error message

PROOF
start a replacement

NOT PROOF
leave it running.
ask the user.

did the program die?

we watched it exit

the same helper that started it
says it's gone

can't reach the machine

it timed out

missing from a list

confusing error message

PROOF
start a replacement

NOT PROOF
leave it running.
ask the user.

The second proof is the clever one. The helper on the remote machine keeps its list of running programs only in memory. So if that same helper — same process, not a restarted one — says a program isn't in its list, it must have exited. There is nowhere else it could be.

And if the helper restarted, it remembers nothing, so we say we don't know. We never treat a fresh helper's empty list as news that your programs died.

Result

What you'd actually notice

SituationTodayAfter
Network drops and comes backTerminals multiply; the remote machine fills with junkYour terminals come back. Nothing invented.
You drag a pane to a new tabA second agent resumes onto the same conversationJust works.
Orca genuinely can't tell if a program survivedSilently starts a new onePane says "disconnected", with two buttons
Leftover programs on a remote machineInvisible, pile up foreverListed with folder and name — you choose what to close
The one visible change⤢ zoom

Orca isn't sure whether
your program survived

TODAY
quietly starts a new one.
you may not notice until
there are two agents.

AFTER
pane shows 'disconnected'
[ try again ] [ new terminal ]

Orca isn't sure whether
your program survived

TODAY
quietly starts a new one.
you may not notice until
there are two agents.

AFTER
pane shows 'disconnected'
[ try again ] [ new terminal ]

This is the decision I need from you

Today, uncertainty gets resolved silently and wrongly. After this, uncertainty becomes visible — a disconnected pane with two buttons.

Slightly more friction in a rare case, in exchange for never resuming your agent twice. I think it's clearly right, but it changes what people see, so it's your call.

Plan

The order we'd build it

Six steps. Each ships on its own and can be undone on its own.

StepWhat it does
1Stop the tab comparison killing live terminalsFixes the double-agent bug. Small, self-contained, helps immediately.
2Stop faking "the program exited"Today a failed reconnect tells the pane the program exited — a claim we can't back up. Ships with the two-button UI.
3Write the notes in one placeThey go to two different places today, which makes the cleanup silently do nothing. This is the actual cause of 2 → 19.
4One piece of code writes the notesTwo paths write them and a third forgets to — which is why an existing safety check never runs during reconnect.
5Check whether an old recovery path ever runsTwo reviewers believe it's unreachable. Measure before building on it.
6The proof ruleOnly if step 5 shows it's needed.

The five words I couldn't avoid

PaneOne terminal box on your screen.
ProgramThe shell or agent actually running — often on another machine.
NoteOrca's record that a pane goes with a program. Saved to disk, so it survives a restart.
HelperThe small program Orca installs on a remote machine to run terminals there.
OrphanA program still running that no pane claims. We list them; we never close them for you.
Why this is smaller, not bigger

It removes roughly 900–1,250 lines and adds roughly 450–700. Most of what goes away exists only to patch up disagreements between notes filed different ways. Once there's one note per pane, that code has nothing left to do.

The detailed versions: counsel-design.html — how this was reviewed and what it cost. report.html — evidence for the work already written. Click any diagram to zoom · scroll to scale · drag to pan.
×
scroll to zoom · drag to pan · Esc to close