[Feature]: Live read-only view of agent sessions running outside T3 (tmux / CLI), with take-over

[charleslefi]

Before submitting

• I searched existing issues and did not find a duplicate. Related: [Feature]: First-class interop/sync between T3 threads and local Claude Code CLI sessions #6590 (import of past Claude Code sessions, completed) and [Bug]: Imported Claude Code threads fail on their first follow-up with "Session ID … is already in use" #15243 (imported thread fails while the CLI session is still in use).
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

I run long-lived agents outside T3 Code: Claude Code and Pi-based agents inside tmux on a remote server, plus one Claude Code session on my desktop. The welcome-wizard import (#6590) brings in past conversations, but a session that is still running cannot be followed from T3:

• the import is a snapshot (200 messages, no tool activity), so it goes stale immediately;
• continuing it from T3 while the original process is alive fails with "Session ID … is already in use" ([Bug]: Imported Claude Code threads fail on their first follow-up with "Session ID … is already in use" #15243);
• sessions running in tmux on a remote environment are not visible at all.

Today I need a second tool just to watch those sessions live, and T3 can't be my single place for all agents.

Proposed solution

A read-only live view of agent sessions running outside T3 on any connected environment:

1. List active Claude Code / Codex / Pi sessions on an environment (from their session files, and optionally tmux panes), marked "external, running".
2. Open one as a thread that tails the transcript in real time (messages and tool calls), without taking over the process.
3. A Take over action once the external process has stopped (or on explicit request), which hands off to the existing import/resume path.

Alternatives considered

• Re-running the import every few minutes: snapshot only, loses tool activity.
• A separate terminal multiplexer viewer next to T3: works, but splits the workflow across two apps.

[odedd]

Note

Claude (AI agent) posting on behalf of Oded.

Adding a concrete, narrower slice of this for Claude Code, which now has a first-class registry for background sessions. That seems a cleaner basis than scanning transcripts or tmux panes.

What exists on the Claude side (verified on Claude Code 2.1.312)

• claude --bg starts a session owned by a per-user daemon, not by any client. It keeps running with nothing attached.
• claude agents --json [--all] lists sessions (interactive and background) as JSON: id, sessionId, pid, cwd, name, kind, startedAt, status, state (seen: working, done, stopped). claude agents without --json is Claude's own "fleet view" TUI.
• claude attach <id|name>, logs, stop, rm and respawn act on those sessions. Detaching leaves them running.
• Transcripts are still at ~/.claude/projects/<cwd-slug>/<sessionId>.jsonl, so the existing scanner can see them. But T3 can't tell which are live, and resuming one from T3 collides with the daemon-owned process (same failure as [Bug]: Imported Claude Code threads fail on their first follow-up with "Session ID … is already in use" #15243).

Use case: I keep dozens of claude --bg sessions going. T3 has no view of them, so I run Claude's agent view in a separate terminal next to T3.

Possible shape, smallest first

1. Server lists sessions through claude agents --json, using the existing Claude executable resolution per provider instance, so it also works for remote environments. Show them as a "Background agents" section with name, cwd, and state.
2. Opening a row opens a T3 terminal running claude attach <id>. This gives full fidelity, including sending input, with no new transcript renderer.
3. Later: the read-only structured tail from the original proposal. "Take over" would be claude stop then the existing resume path.

Steps 1 and 2 reuse existing pieces (the Claude driver's executable resolution, the terminal manager) and avoid reading daemon-internal files. Only the documented CLI surface is needed.