feat: way to view output from tool calls / commands

[maria-rcks]

[rozatoo]

Extra context/Ideas:

• Easily switch between display output vs collapse output by default
• Color based on success or failed exit code?
• View output in full screen? (Nice for really long outputs like tofu plan)
• Maybe a way to have it auto-expand on only commands that require approval?

[HabsaTheDog]

Yes this is also good to understand if there is a wrong tooluse or broken commands the Agent is using.

[aashishsingla567]

Also, some observability on the Subagents spawned by Codex etc. would be great. They are also invisible right now.

[jeroenev]

Yeah, visibility should be improved for both subagents and tool calls.
I was hoping that T3code would have better visibility now that OpenCode is no longer allowed to use Anthropic Subs (Opencode does this best imho, especially for subagents)

[Quicksaver]

Related with usable code/references:

• Expandable File Change and Command activity boxes #3005
• Subagent support as nested threads #538 (comment)

[juliusmarminge]

PR #4083 has been refreshed without opening a new PR: branch codex/refresh-pr-4083 at commit bf58a964cd. The echoed-command/output defect is covered by 62 focused tests and real-app before/after evidence. Status remains 🚧 In Progress until merge.

[prom3theu5]

Any ideas when this will be in - im one of the sadists that likes to run claude desktop in verbose mode - i like to see whats occurring on all tool calls :)

[ineffyble]

This is my main blocker, want to be able to use T3 day-to-day but not being able to actually see the outputs of commands is too limiting.

[ben-vargas]

Yeah, +1 on this... I do a lot of work with custom CLIs connecting to enterprise software. Without being able to see the full bash tool calls and their outputs, I really can't rely on T3 for day to day "day job" work. I need to know when a bash/shell tool call doesn't behave as expected or needs optimization, T3 obfuscates that all.

I get that this was probably a design decision to keep things "friendly" and "simple" for the vibe coder initially, but an advanced option to show the outputs is very much required for adoption.

[mikenrafter]

Throwing my hat into the ring... I also greatly desire visibility. Frankly the only reason I'm using T3 in spite of this glaring oversight is its wonderful session management and remote-use combined with subscription-account compatibility.

[prom3theu5]

Recent changes to reduce payload sizes seems to limit the command output to the first line only, making it pretty useless

Could we get a new command introduced, that queries and returns this content from the persistence layer upon expanding a toolcall output selector?

This way payloads stay small for session catchup / resume on mobile, and only return full payload when requested?

[IcTxDiogo]

Validating the on-demand shape sketched above: we run exactly this architecture locally. The projected timeline payload stays bounded for catchup and resume, and the full persisted payload is fetched explicitly only when a tool entry is expanded, plus verbatim copy. It keeps the normal timeline light while making arbitrarily large outputs reachable, and it composes well with the recent payload-slimming direction: the inline bound then only has to cover the common case, not the worst one. Happy to share design notes if the team picks this direction up.

[AKolenda]

Hey! I’ve been working on this exact problem for subagents and have made good progress. There’s now a working implementation in PR #10881, along with a more complete feature proposal in discussion #11000.

The goal is pretty simple: when several agents are working, I want to open one and understand what it has actually been doing—without interrupting the parent conversation or restarting the child.

The new Agents panel stays compact by default. Clicking an agent shows its latest tools, and Open full activity takes you to its saved messages, commands, outputs, reasoning when available, file edits, and final response. It opens at the latest activity, tool output and patches expand only when clicked, and the agent’s final message stays easy to read.

Collapsed overview	Full activity for one agent

What the original Agents tab looked like

The original tab was useful as a roster, but it only showed status and the latest activity label. There was no way to inspect a child agent’s saved work from here.

See the expanded recent-tools view

Implementation and validation details

The history is fetched on demand from the environment that owns the thread, so complete child transcripts do not need to ride along with every projected thread update. Opening history is read-only: it does not start, resume, or interrupt the child or parent session.

Codex and Claude were checked against local native saved history. OpenCode and Grok have protocol-backed implementations but still need native end-to-end verification. Cursor and Antigravity remain unsupported because T3’s current ACP integrations do not expose a verified combination of durable child identity and read-only child history.

Repeated history reads reuse short-lived provider connections rather than continually launching new processes. The work has 335 focused tests covering provider routing, ancestry checks, pagination, malformed native records, connection cleanup, and panel behavior. I also built and exercised a Linux AppImage with real saved child activity.

This work directly covers output and messages for subagents in the Agents panel. The broader request in this discussion also includes full tool output in the parent timeline. I think the same on-demand approach fits there, but that part would still be separate work.

The PR includes a short interaction recording too. Even if the maintainers prefer a smaller rollout or their own implementation, I hope the working prototype and provider findings make the feature easier to evaluate and carry forward.

[prom3theu5]

Nice

Aye I understand Theo's standpoint from why he doesn't need this - its because he doesnt babysit any threads manually - if you look at his latest "how I work video"
And while for 80% of the time that works - it definitely does not fit everyone's use cases of a Harnes / cerebral orchestrator.

Unfortunately this isn't possible with some threads - For instance I've a large microservice stack im working in wwhere sandboxed agents are spinning up multiple services, and i've just stopped one that wwas going for 3 hours while I slept because it had a docker socket issue it was trying to work around - but if I could have seen the command output from what it was running I could have told it exactly what testcontainers ryuk's issue was straight away without it trying to guess and waste 3 hours worth of tokens lol

Its the only limiting factor in t3 from what I see.
I use it as my daily driver still because it is better than everything else i've tried in all other aspects - but this lack of observability is driving me insane, and with the rate we are going through releases, i dont want to fork it because a - rebasing daily will be a nightmare, and b - maintaining a set of patches will be the death of me lol