[Bug]: iOS work log hides tool identity behind generic `Tool` / `Tool updated` rows

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile (iOS)

Summary

On iOS, expanded work-log activity often renders as generic rows such as Tool and Tool updated, without saying which tool ran, what it operated on, or what changed. In a delegated/subagent-heavy turn this makes the work log effectively opaque even though the server/provider clearly has more structured tool metadata.

The screenshot that prompted this report is a real iOS thread where the parent agent says it restarted three workers and explains what each worker is resuming. Immediately below that, the expanded work log contains rows like:

Worked for 1ms
  Tool updated

Used 2 tools
  Tool
  Tool

Worked for 1ms
  Tool updated

Tool updated
Running ps
ps -o pid,etime,stat,cmd -C ninja -C cmake -C gd...

The Running ps row is useful because it identifies the operation. The adjacent Tool / Tool updated rows do not provide comparable information, so from the phone there is no way to tell what most of the visible work actually is.

This also makes the surrounding mobile observability gaps much more obvious: the parent text can say that multiple subagents are active while the work log underneath gives almost no clue which agent is doing which operation. That broader subagent-visibility problem is tracked separately; this issue is specifically about the loss of useful tool identity/details in mobile work-log rows.

Steps to reproduce

1. Open a thread in the native iOS app.
2. Run a provider turn that performs several tool calls, ideally with delegated/subagent work.
3. Expand the Worked for ..., Used N tools, or other work-log groups while the turn is running or after it settles.
4. Observe tool lifecycle rows.

Expected behavior

Tool rows should expose enough structured information to understand the operation without leaving the thread. At minimum:

• identify the tool/action (Read file, Ran command, Edited file, Searched the web, Spawned subagent, etc.);
• show a concise primary target/argument where useful (file path, command preview, query, task name, etc.);
• preserve that identity while a call transitions through started/updated/completed states rather than falling back to generic Tool updated;
• when expanded, show bounded input/output/detail that is already safe to project to the client;
• collapse repeated lifecycle updates for the same call into one stable row rather than making the user infer that several generic rows are the same operation.

If agent attribution is available for a tool call, showing the agent name/role or linking to the existing Agents surface would make delegated work substantially easier to follow, but that is secondary to exposing the tool identity itself.

Actual behavior

Many mobile rows show only Tool or Tool updated. Those labels communicate lifecycle state but not the operation itself. A user can see that something happened, but not what happened.

In a multi-agent turn this can produce a transcript that effectively reads:

parent agent: networking worker resumed
parent agent: physics worker resumed
parent agent: Cocoa worker resumed

work log:
Tool updated
Tool
Tool
Tool updated
Tool updated

That defeats much of the purpose of exposing a work log on mobile.

Impact

Major UX degradation for remote monitoring of long-running agent work. From iOS it is difficult to tell whether an agent is making progress, repeating itself, touching the wrong file, running tests, or stuck. The workaround is to inspect the machine out-of-band (terminal/ps) or ask the model what it is doing, both of which defeat the point of the work-log UI.

Version / environment

• Native iOS T3 Code app
• Exact mobile build/version was not visible in the captured screen
• Thread contained multiple delegated/subagent workers and several tool lifecycle events

Related work

• #7152 — merged web work that collapses tool activity into useful labels such as Running pnpm, Ran N commands, and Changed N files; its PR explicitly left mobile parity to follow-up work.
• #5847 — closed/unmerged web PR that humanized tool rows from provider metadata (Read file, Ran command, Searched the web, etc.) and explicitly noted that mobile still showed the old headings.
• #6402 / #4962 — mobile subagent visibility/background-liveness work; related because generic tool rows are especially painful when several workers are active, but this issue is narrower.
• #11784 / #10945 — reasoning/thinking visibility work; separate from this bug, but together the missing reasoning + generic tool labels can leave a mobile turn with almost no useful explanation between the prompt and final answer.

Suggested direction

Mobile should derive tool presentation from the same structured provider payloads / shared presentation helpers as web wherever possible, rather than rendering lifecycle-generic labels. A shared describeToolCall... path would also reduce web/mobile drift going forward.

Start in apps/mobile with the work-log rendering path, then trace how tool lifecycle rows receive structured provider metadata. Compare the existing web presentation described in #7152 and #5847. Done means mobile rows identify the tool and a bounded target or detail, while repeated lifecycle updates remain stable and understandable.