Sessions
The Panel labels a unit of harness work as a Session. In the product's own types that unit is a Task — a run of a Harness against a project's files. Only rendered strings say Session. The live conversation behind it (the PTY plus the Harness's own session id) is also called a session in the domain; you do not need both words at the keyboard.
What you type into is a real PTY on the Core, streamed to the browser over the panel-link. It is not a transcript view. Bytes go both ways.
Status
Sessions split into three buckets you can scan from Fleet and from the grid:
| Bucket | Meaning |
|---|---|
| needs-input | The Harness stopped to ask a question or grant a permission. |
| running | The Harness is working. |
| finished | The turn ended. |
Per-project counts use the same buckets, so a machine waiting on you is visible without opening it.
Who may type
At most one connection may write into a session. Everyone else attached to it can read every byte and write none of them.
That exclusive write is a session lock, held by a core-link connection — the Panel as a whole, or an actana session attach, not a person. If another client already holds it, this tab is read-only.
Which of your Panel tabs types is separate: session drive is local to the Panel. Two tabs are one operator. The first pane that opens on a session nobody in this Panel is driving takes the keyboard; a later tab follows and may ask for it. The Core never hears about that.
You only need this: one writer, others read. A following tab is not the same as a session another client holds.
VM shell
New Terminal opens a VM shell session: a free-form interactive shell on the Core's machine. It is not a Harness and it is not bound to a project folder. Same core-link auth; you open it on purpose. It is the SSH-equivalent escape hatch, rendered like a user terminal.
