[FEATURE] Let Workflow (dynamic workflow) subagents render in tmux panes, like teammateMode: "tmux" does for agent teams

The gap between team agents (tmux pane visibility) and workflow subagents (headless API loops) is a real UX discontinuity. You get full observability when running agent teams, then lose it entirely the moment you switch to dynamic workflows — which is exactly the context where fan-out counts and silent failures matter most.

The 70-agent case you described illustrates the core problem: with team agents you would have seen 26 panes go dark. With workflow subagents you're grepping jsonl files after the fact.

One partial workaround some people use while waiting for first-class support: spawn workflow subagents in a separate tmux session explicitly via a PreToolUse hook that intercepts the Workflow tool call and passes teammateMode: "tmux" equivalent config before each agent() invocation. Brittle, but it does give you pane visibility. The real ask — letting the Workflow engine inherit the same tmux rendering path team agents use — is the right fix and worth the team's attention.

If you're running this scale of workflow regularly, session management across that many concurrent agents is the kind of coordination problem that benefits from tooling built specifically for it. Worth keeping an eye on what's coming in the orchestration-layer space.

I also would like the option to view what the agent is doing in the workflow view for an agent. Kind of expected it to work that way... being able to talk to the agent would also be nice.

Supporting this, with a data point that widens it slightly and a finding that I think narrows the design space usefully.

The same gap exists for Agent-tool subagents, not just Workflow agents. #34468 is that ask — it was closed NOT_PLANNED, but by the stale bot for inactivity rather than on merit, so this thread is the live one.

Asks 2 and 3 are much closer than ask 1

I went looking for an interception point for subagent spawns and found there isn't one — but the data those two asks need already exists today.

SubagentStart / SubagentStop hook payloads carry, per agent:

agent_id, agent_type, session_id, transcript_path, cwd, hook_event_name

Verified on 2.1.220 (Linux x86_64, native) against my own hook log — agent_id is stable per agent across start and stop, and transcript_path points at the live agent-*.jsonl. So a claude workflow tail (ask 2), or documenting the transcript layout as a stable interface (ask 3), is largely a matter of blessing something already emitted. Anyone can build an external watcher on it right now; the reason to make it official is exactly the stability point in ask 3.

Ask 1 can't reuse the teammateMode path, and it's worth being explicit about why

Teammates get panes because a teammate is a separate OS process: Claude Code splits a pane and execs a new claude binary into it. That spawn is interceptable — there's an (undocumented) CLAUDE_CODE_TEAMMATE_COMMAND env var that Claude Code execs in place of the binary, which is how tmux-based setups relocate the pane afterwards.

Workflow agents and Agent-tool subagents are in-process API loops. No binary invocation, no PTY, no pane. This matches the docs' own framing — teammates are "separate Claude Code instances", subagents "run within a single session" — and the agent-view docs say background agents "do not create tmux panes, windows, or pseudo-terminals".

So ask 1 isn't "let workflow agents inherit the tmux rendering path"; that path doesn't apply to a thing with no PTY. It's either giving subagents real PTYs, or synthesising a pane and streaming into it — a genuinely bigger change than 2 or 3. Not an argument against it, just against the estimate.

On the PreToolUse workaround suggested above — intercepting the Workflow call to pass a teammateMode: "tmux" equivalent: I don't think that can work, for the reason above. There's no per-agent spawn for a PreToolUse hook on Workflow to intercept, and no config on that call that turns an in-process agent into a process with a TTY. The buildable version today is a SubagentStart/SubagentStop hook that opens one pane and tails the transcript_paths it's handed — status visibility, not a pane per agent.

One caveat for ask 3

agent_type is not consistent across interfaces. An agent spawned as subagent_type: "fork" reports agent_type: "fork" in hook payloads, but the same agent reports agent_type: "general-purpose" in the statusline payload — so a watcher keyed on one can't be cross-referenced against the other. If transcripts and identifiers are going to be documented as a stable interface, that's worth reconciling first, otherwise ask 3 documents an inconsistency.

This is exactly one of the problems I ran into when building Hackeroom.

I wanted multi-agent workflows to be observable without having to jump between individual Claude Code sessions or inspect JSONL transcripts after the fact.

My approach was to make the orchestration layer itself visual. Each team member is a real, independently running Claude Code session, and the UI represents the members/workflow state rather than trying to render the internal Agent/Workflow TUI.

For example:

Planner → Coder → Reviewer → Tester → Auditor

I can see which member is running, what role it's performing, its current state, and the handoffs between members from one place.

hacker room

I think there's an interesting distinction here between:

• making in-process subagents have their own PTY/TUI
• exposing a stable event/transcript stream
• building an external orchestration UI over independent Claude Code sessions

The second option seems particularly useful for external tooling because you don't necessarily need to reproduce the Claude Code TUI — you just need a stable stream of agent lifecycle/activity events.

I'd love to see an official workflow tail/agent event stream API. That would make building external visualizers much less dependent on transcript internals.