Consider a first-class hosts/peers read UX

[schickling-assistant]

Problem

pty-relay already owns the remote pairing/transport model, but the CLI UX for discovering and reading from already-paired relay endpoints is a little hard to expose from higher-level tools without inventing local vocabulary. Downstream wrappers can end up naming this as a "fleet" even though the real abstraction is just relay hosts/peers.

Suggestion

Consider a first-class read-only host/peer UX, for example:

pty-relay hosts list
pty-relay hosts peek <host> <session>

or, if this belongs in pty as the user-facing entrypoint:

pty hosts list
pty hosts peek <host> <session>

Design constraints

• Keep pty-relay as the source of truth for pairing and transport.
• Avoid introducing a separate "fleet" abstraction unless there is a new topology model beyond relay hosts.
• Keep this read-only at first: list paired/reachable hosts and peek existing sessions.
• Preserve existing relay approval/security behavior.

Why upstream

A small upstream vocabulary would let downstream systems expose remote PTY reads without diverging or wrapping relay semantics with product-specific names.

Posted on behalf of @schickling

field	value
agent_name	🏗️ co1-moraine
agent_session_id	5da54112-daf9-403c-af37-acb682362ac5
agent_tool	Codex CLI
agent_tool_version	0.137.0
agent_runtime	Codex CLI 0.137.0
agent_model	unknown
runtime_profile	/nix/store/4p78dsfk8riqcgk91zzjlgraibyf1hd4-coding-agent-runtime-profile/share/coding-agents/profile.json
skills_manifest	/nix/store/cly1vi1qvxfyk37gmdk4qw4j33zrfpny-agent-skills-corpus/share/agent-skills/manifest.json
worktree	dotfiles-pty-relay-hosts
machine	dev3
tooling_profile	dotfiles@e7e383b

[myobie]

The read-only / no-fleet / preserve-existing-approval constraints all match my intent. Let's go with pty-relay hosts list + pty-relay hosts peek <host> <session> as the v1 home.

Reasoning: keeps pty-relay self-contained (no IPC or shared-state dependency from pty into pty-relay's pairing state, no need for pty to learn about relay semantics on startup), keeps the source of truth where you correctly identified it lives, and keeps the surface easy to revise pre-release. If downstream patterns later warrant unifying under pty hosts ... as a thin facade, that's an additive promotion — much cheaper than going the other direction.

Pre-release timing also helps: we can shape the vocabulary before downstream wrappers stabilize on the relay-specific name.

Happy to review a PR.