Every codex seat resolves its pane to the one the app-server was launched from

[fujibee]

Every codex seat resolves its own pane to the same pane, and it is not theirs.

seat        placement record      naming mark        actually in
agdev-co1   herdr:w1:pJ (stale)   herdr:w1:p2        w1:p2
agdev-co2   herdr:w1:pN           herdr:w1:p2        w1:pN
agdev-co3   herdr:w1:pP           herdr:w1:p2        w1:pP

Three seats, three different panes, one answer.

This was measured rather than reasoned into: agdev-co2 had no reference in its mark at all, was asked to run one send.sh, and wrote herdr:w1:p2 — a pane belonging to a different seat. The wrong value is produced on demand, so it can be reproduced at will.

Why

Self-naming resolves "which pane am I in" from the environment. A codex seat does not get its environment from its pane: it reaches this machine through a shared app-server daemon (Remote: ws://127.0.0.1:… in its own header), and every session under that daemon inherits the environment of wherever the daemon was started. That is w1:p2. So the question "which pane am I in" is answered, for all of them, by the pane the daemon happens to have been launched from.

It is not that codex seats fail to name themselves. They name themselves confidently and identically, and the answer is somebody else's pane.

Why this looked like three bugs

Read one seat at a time, the symptoms differ: one has a stale placement record, one had an empty mark, one points at a neighbour. Read together, the marks are identical and only the placement records differ — and the placement records differ because they came from spawn, which knew the real pane at launch. The half written by the seat is uniformly wrong; the half written by the spawner is right where it exists and stale where the seat has since moved.

Earlier versions of this issue described this as "codex never records its mark" and then as "three different wrong answers". Both were artifacts of looking at seats individually. The correction that mattered was putting all three side by side.

What a fix has to establish

A codex seat cannot trust an inherited environment variable to say where it is. Something else has to answer:

• the terminal can be asked which pane holds a given process or agent session — the herdr driver already resolves a session id to a pane elsewhere, and that path does not depend on inheritance;
• or the seat's identity in the terminal (its agent session) is the key, and the pane is derived from it rather than read from the environment.

Whatever the route, the test is the one above: three seats in three panes must produce three answers. A test with a single seat passes today.

Acceptance

• Each codex seat's mark names the pane it is in, verified with at least three seats in different panes simultaneously.
• A seat never writes a pane reference that another seat's mark already claims.
• agdev-co1's pane, relabelled .dotteam:alice by a test thirteen hours ago, is restored by its occupant on its next action.
• The claude-code path keeps working — it resolves from the environment correctly because its process really is in that pane, and that must not be broken while fixing the case where it is not.

[fujibee]

This is not only unrepaired — it is now positioned to break something that works.

Measured after #1111 landed and the panes were repaired by hand:

pane     label                 placement record   state
w1:pN    agmsg:agdev-co2       agdev-co2          correct
w1:pP    agmsg:agdev-co3       agdev-co3          correct

Both codex seats are currently correct, and correct for one reason: spawn wrote those placement records at launch, when the real pane was known from outside. Nothing since has overwritten them.

#1111 changes that. A seat now records its placement when it acts — which is right for a process that can tell where it is, and wrong for one that inherits a stale answer. The next time agdev-co2 runs send.sh, it resolves w1:p2 and writes that as its placement. A record that is right today gets replaced by a wrong one, by the mechanism that exists to keep records correct.

That already happened to the mark: agdev-co2 had no reference at all, ran one send.sh on request, and wrote herdr:w1:p2. The mark and the placement record are written on the same path.

So the ordering matters. #1111 is correct for claude-code, where the environment really does describe the process's pane, and is actively harmful for codex, where it does not. The two landed a few hours apart and the second one makes the first one dangerous for one of the two types.

Until this is fixed, a codex seat that acts loses a correct placement record. The current 7-of-10 measurement is a snapshot taken before those seats acted again.

[fujibee]

Measured: both existing self-identification routes give the same wrong answer

Measured on the live workstation with three codex panes in one herdr workspace.

1. The environment route is inherited, not local

A codex session reaches the machine through a shared app-server, so the shell
commands it runs execute in the app-server's process tree rather than in its own
pane. HERDR_PANE_ID therefore reports wherever the app-server was launched.
All three panes reported the same pane id while sitting in three different panes.

2. The session-id route disagrees with what is actually running

_herdr_pane_for_session exists in the herdr driver, but agent list's
agent_session does not match the thread actually running in the pane. Live
thread ids read straight off each pane, against what agent list records:

pane	thread actually running	agent_session recorded
B	01a07b10-…	01a0732c-…
C	01a07b11-…	01a0732d-…
A	(not observed)	01a07b11-… — which is C's thread

Resolving C's live thread through agent list returns pane A. That is the same
wrong pane the inherited environment gives. Two independent routes agreeing on a
wrong answer is not a coincidence to route around; both are unusable here.

3. The pane label is correct

Checked without circularity, by matching each pane's own screen buffer against
its label:

pane	label	seat name visible in the buffer
A	<team>:<seat-a>	<seat-a>
B	<team>:<seat-b>	<seat-b>
C	<team>:<seat-c>	<seat-c>

3 of 3. The label is written by spawn, which knows the pane it created, so it
depends on neither the inherited environment nor agent_session.

Proposed fix

Add a label match to the self-identification order. A seat already knows its own
team and agent — they are the arguments to agmsg_terminal_name_self. When
exactly one pane carries the label <team>:<agent>, that is the seat's pane.

Order: label match (only when it resolves to exactly one pane) -> environment ->
session id. Zero matches or more than one falls through to the existing routes.

The claude-code path resolves correctly from the environment today and must keep
the same answer; that belongs in the regression tests. Bootstrap (no label yet)
has no label to match and falls through, which is correct — a spawned seat gets
its placement record written by spawn directly.

Note on the earlier measurement

The comment now in ops.sh records a 2026-09-08 measurement finding 176 of 176
processes in the pane agent list reported. That population was drawn from
processes carrying both a pane id and a CLI session id, which does not reach the
shared-app-server case: those seats do carry both, and both values are wrong
together. The conclusion held for the sample and does not hold for this class.

[fujibee]

agmsg already holds the correct session id; herdr's map is the part that is wrong

Reading a codex seat's own naming mark:

session=<thread-id>                 <- matches that seat's live CODEX_THREAD_ID
renamed_ref=<the shared wrong pane> <- the inherited answer
rename_result=skipped:unknown:name_not_visible

The seat records its session id from its own environment, and that value is
correct and distinct per seat — CODEX_THREAD_ID is per-thread and is not shared
the way the pane id is. So the missing piece is not the seat's identity. It is
the thread-to-pane map, and the copy herdr holds does not match what is running.

herdr accepts a correction

herdr pane report-agent-session <pane> --source <id> --agent <label> --agent-session-id <id> writes the pane's agent-session identity, and
herdr pane report-metadata <pane> --source <id> --title <text> writes a
display-only title that is stored separately from the OSC-derived
terminal_title (verified live: setting it on a codex pane produced a title
field alongside an unchanged terminal_title).

Once a seat knows its own pane by the label match described above, it also knows
the correct (pane, session id) pair and can report it back. That repairs the map
for every other consumer instead of routing around it.

What a live canary showed about the current stop-gap

A codex seat was asked to run one ordinary action while three panes were watched
for 200 seconds. No pane label changed, no placement record changed, and the
seat's own mark was not rewritten. The stop-gap's guard sits after the naming
step, so a rewrite was possible in principle; it did not occur in this run. The
guard should still move ahead of the naming step, but this is not currently
causing damage on top of the wrong resolution itself.