[Feature Request] See subagent logs live in tmux panes while they run (view-only)

[seungminio]

What I want

When I work with gjc --tmux, I'd like each subagent to automatically open its own tmux pane showing its progress logs as it runs, and have that pane close by itself once the subagent finishes. View-only is fine — I just want to watch, not interact with the pane.

Why

Right now, even with gjc --tmux, everything happens in a single window. When subagents fan out, I can't see what's happening inside each one in real time. When several subagents work at once, I'd like to follow along with "what is each one doing right now," but currently I can only check the results after everything is done.

I know gjc team gives me visible workers, but going through team's full worker/worktree/lifecycle process feels like overkill for lightweight in-session parallel work. I'd love a lighter option that just lets me "watch the subagents that are currently running" in side panes, while leaving the subagents running exactly as they do today.

Expected behavior

• A subagent starts → a new pane opens and shows that subagent's logs live
• A subagent finishes (completed / failed / aborted) → its pane closes automatically
• When not inside tmux (App, non-interactive, RPC, etc.) → nothing happens (silently skipped)
• Opt-in — default stays exactly as it is today, turned on only when I want it

Why I think this might be feasible without changing the execution model

I poked around the code a bit, and it looks like most of the pieces already exist, so this could be a thin "observation only" layer rather than a rewrite:

• Each subagent's full transcript already seems to be written to disk in real time as <artifactsDir>/<taskId>.jsonl (the executor has a comment along the lines of "input and jsonl already written in real-time"). So a pane could just follow that file — no separate process needed.
• There already appears to be a lifecycle broadcast (TASK_SUBAGENT_LIFECYCLE_CHANNEL) carrying status (started / completed / failed / aborted / paused) plus the sessionFile path. That maps cleanly onto "split a pane on start, kill it on finish."
• There's already a similar precedent in the harness: a viewportHandle of kind event-monitor with viewOnly: true that surfaces an events stream as a tmux monitor.
• tmux split / kill / layout helpers already exist (used by the team runtime and tmux-common).

So in principle the new work could be limited to: subscribe to the lifecycle channel → on started, split-window and tail the subagent's jsonl → on terminal status, kill-pane. The subagents would keep running in-process exactly as now; the panes are purely a live view.

Open questions

• Concurrency: subagents can run many at once (looks like up to ~15 concurrent). Opening that many panes would wreck the layout. Should there be a cap, a queue, or a single rotating viewer pane that cycles through active subagents?
• Activation surface: env var vs CLI flag vs setting?
• Readability: the jsonl is the raw session format, so a plain tail -f would show raw JSON. Is a v1 with raw tail acceptable, or should it ship with a transcript renderer from the start?
• Architecture boundary: today the project seems to intentionally separate "visible tmux workers = team" from "subagents = in-process." Does a view-only pane layer conflict with that intent? If it does, I'd rather confirm the direction before anyone invests in it.

Non-goals

• Changing how subagents run (keeping them in-process is totally fine)
• Controlling subagents from the pane (watching is enough)
• Replacing gjc team

[Yeachan-Heo]

Thanks for the detailed feature request. This is a plausible usability improvement, but it changes the interactive tmux/subagent observation surface, so I’m marking it as a maintainer-owned design decision before implementation.

Current triage: OWNER_CONFIRMATION_REQUIRED.

Notes for the eventual design pass:

• Must stay opt-in; default behavior should not change.
• Must be view-only and skip cleanly outside tmux/non-interactive/RPC contexts.
• Must not change subagent execution semantics or lifecycle ownership.
• Needs careful pane cleanup/failure handling so this does not create terminal/session leaks.

Holding for maintainer direction rather than spinning an implementation PR immediately.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Thanks — I’m checking this against the current subagent/tmux/session architecture. Since this touches operator-visible session behavior, I’ll either keep the implementation very narrow and view-only, or hold it for an explicit maintainer decision if the contract surface is broader than it first appears.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Current dev triage after checking the subagent/tmux code: this is not already fixed by recent merges. The existing pieces are present (TASK_SUBAGENT_LIFECYCLE_CHANNEL, real-time subagent session JSONL, and tmux split/kill helpers), but there is no opt-in tmux viewer layer today.

I’m keeping this as OWNER_CONFIRMATION_REQUIRED rather than opening an implementation PR, because the unresolved design choices affect the operator-visible session contract:

• activation surface (GJC_* env vs CLI flag vs setting)
• pane fan-out policy/cap for many concurrent subagents
• raw JSONL tail vs a first-class readable renderer
• whether view-only subagent panes are acceptable alongside the deliberate gjc team visible-worker boundary

Smallest safe implementation once direction is confirmed: an opt-in interactive-tmux observer that subscribes to lifecycle events, opens a detached view-only pane for each started subagent up to a configured cap, tails/renders the emitted sessionFile, and kills the pane on completed/failed/aborted/paused, silently no-oping outside real tmux / RPC / non-interactive contexts.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Work started / triage session opened.

Session: gajae-code-issue-607-subagent-log-panes
Worktree: /home/bellman/Workspace/gajae-code-issue-607-subagent-log-panes
Status: feature triage session live; inspecting subagent live-log pane feasibility and existing runtime surfaces.

This is a dedicated GJC tmux session using the raw default-tmux + clawhip-watch path, so the session should remain inspectable even if the child process exits.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Closing this as an owner-confirmation/design-scope item for backlog hygiene. The implementation shape is documented above; reopen or file a focused implementation task when the activation surface and pane policy are decided.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]