A session cannot learn its own peer address, so it cannot tell a session it spawns how to reply

[defangdevs]

What happened

A coordinating session spawned a worker with agent-box-session add --profile … --prompt "…report back with SendMessage…". The prompt has to name a reply address, and there is no way for the spawning session to know its own. ListAgents lists peers only — your own session is never a row — so the coordinator guessed, picked a name it had seen in an earlier listing, and the guess belonged to a different session entirely.

Everything the worker sent went to that stranger for the first several minutes of a live three-cloud deployment. The worker's own words:

confirmed, that addressing bug cost me some time (I was misrouted to tmux "opus" the whole time)

The second half: what ListAgents prints is not accepted by SendMessage

Once the worker looked for the coordinator itself, it found the row but still could not use it:

ListAgents shows your row as claude@nixos.defang.ca: with tmux main:@0.%0, but SendMessage rejects that exact string ("to must be a bare teammate name") — I could only reach you by copying the raw from= socket address off your incoming message.

So a session with no /rename topic is listed under a name (<user>@<host>:) that the messaging layer refuses. The only reliable address was the uds:/tmp/cc-socks/<pid>.sock value from an inbound message — which only exists after the other side has messaged you first, and is useless for the spawn prompt, which is written before anyone has said anything.

Why it matters

Fan-out through agent-box-session add --prompt is the documented way to parallelize work, and the guide tells a dispatched session to report back. Today that instruction cannot be written correctly by the session issuing it. The failure is silent: messages are delivered, just to the wrong session, and the spawner sees only that nothing arrived.

Reproduce

1. From session A (no /rename, tmux main), run ListAgents — note A is absent.
2. agent-box-session add worker --prompt 'reply to <whatever A guessed> with SendMessage'.
3. In the worker, run ListAgents; A appears as claude@<host>:.
4. SendMessage({to: "claude@<host>:", …}) → Error: to must be a bare teammate name — there is only one team per session.

Possible fixes, in the order I would want them

1. Let a session see its own address. Either mark the caller's own row in ListAgents ((you)), or add a whoami-style field to the result. Then a spawn prompt can carry a correct address.
2. Accept the string ListAgents prints. Whatever appears in the to-column of a listing should be a valid to. Right now a listed name can be unroutable, with an error that reads as user error.
3. Give a session an address that survives having no topic. <user>@<host>: with an empty tail is the shape that breaks; a name that is always bare would sidestep the whole problem.

Failing all of that, the guide's "report back to the session that spawned you" advice needs a documented recipe — e.g. have the spawner send the worker a first message so the worker can reply to its from=.

Environment

• agent-box on NixOS, claude harness, worker started with agent-box-session add --profile awsdeployer --prompt …
• Observed 2026-09-05.