[idea] Server-assigned pane provenance: who created this pane

[jefflitt1]

idea / problem

A pane record tells me everything about a pane except who made it. On 0.8.2 pane list returns
agent, agent_session, agent_status, cwd, focused, foreground_cwd, pane_id, revision,
scroll, tab_id, terminal_id, terminal_title, terminal_title_stripped, workspace_id, plus
optional label, title and tokens. There is no field for the pane's origin and no parent
pointer.

Process lineage cannot substitute. Every pane shell is a child of the herdr server, so PID/PPID is
flat — a pane an orchestrator opened with pane split + agent start looks exactly like one I
opened by hand.

The practical effect, with 6–10 panes on screen: I cannot tell which panes are mine and want my
input, and which are background workers that should report back and go away. Everything I can key
off — an agent name, a label, a metadata token — is something the caller writes about itself, so it
is a convention that holds only as long as every caller cooperates.

Two smaller things fall out of the same gap:

• There is a window between pane split and whatever the caller writes to mark the new pane. If the
  caller dies in that window, the pane exists with nothing on it, and any rule of the form "an
  unmarked pane is the human's" quietly stops being true. Discussion [idea] herdr pane split --label <text> (atomic create-with-name like tab/workspace) #584 already asks for
  pane split --label for the labelling case; a token form would close the same window for
  metadata.
• pane report-metadata <pane_id> --source <id> --token k=v accepts any pane id from any local
  process. I confirmed this by writing a full set of my own tokens onto an unrelated live pane. So a
  mark is evidence that someone wrote it, never that the pane's owner did.

To be clear about the framing: this is cooperative metadata between processes that already run as
me, and I am not reporting a vulnerability. The consequence is not that someone attacks me — it is
that automation built on these marks cannot state a property it actually holds, so it stays
conservative and does less than it could.

requested change

A created_by on the pane record, assigned by the server rather than reported by the caller —
identifying the calling context at creation, ideally the caller's own HERDR_PANE_ID when the call
comes from inside a managed pane, and something distinguishable when it does not. Immutable, and
present on every pane whether it was created interactively or over the socket.

That one field would settle it: an orchestrator-created pane is identifiable without the
orchestrator having to say so, and a pane with no created_by pointing at a managed pane is the
human's.

Secondary, and only if the first is interesting: some notion of caller identity on
report-metadata, so a pane's own marks can be told apart from marks a third party wrote. Worth
noting against #481/#514 — that proposal's tiering puts pane.report_metadata in the unrestricted
tier, so it would not cover this.

why you want this

Anything that acts on panes on the human's behalf — reaping finished workers, sorting the sidebar by
who needs attention, routing notifications (#2529), stacking children under a dock (#1778) — needs
to know which panes are the human's. Right now every integrator answers that question with private
state kept outside herdr, and each one answers it slightly differently.

what I do today

I ship a plugin that stamps its own panes with report-metadata tokens at spawn time and a private
ledger, written only by the spawn wrapper, that records the panes it created. The reaper requires
both: a pane is only closed if it carries the stamp and appears in the ledger, so a stamp alone is
never authority to close anything. Unmarked panes are treated as the human's and are never touched.

It works and I am not blocked. But it is a second source of truth that has to be kept in sync with
herdr's, it does not survive a crash between split and the stamp, and it only covers panes that
went through my wrapper — any other code path calling pane split directly produces a pane my
plugin reads as human-created. All three of those are consequences of the same missing field.

related

• [idea] herdr pane split --label <text> (atomic create-with-name like tab/workspace) #584 — pane split --label (same atomicity window, labelling case)
• Multi-agent child panes cannot reliably stack on a right dock without external ownership state #1778 — multi-agent child panes need external ownership state
• Record caller attribution for focus events #2930 — caller attribution on focus events
• Expose root lineage for OpenCode agent sessions #2830 — root lineage for agent sessions
• Sub-agent management and visibility? #1274 — subagent visibility; a commenter there is nesting panes by metadata token with
  "creation lineage as the fallback", i.e. the same workaround
• Socket API has no caller authorization - sandbox escape via agent.start / pane.send_text #481 / Socket API has no caller authorization - sandbox escape via `agent.start` / `pane.send_text` #514 / Security hardening: update-integrity trust chain and local control-socket authentication #990 — socket API caller authorization

Environment: herdr 0.8.2, stable channel, macOS, Ghostty, zsh.