fix: show the runtime icon on a profile-launched tab - #672
Conversation
A profile launch creates its tab with a hardcoded terminal glyph and leaves the rest to CommandIconMap, which resolves an icon from the first token of the command in the shell title. The launch command is `env CLAUDE_CONFIG_DIR=… claude`, so that token is `env`; nothing matches, and by contract an unmatched token leaves the existing icon untouched. The placeholder therefore stays for the life of the tab: typing `claude` by hand shows the brand icon, launching the same agent from the Agents menu does not. The launch path already knows its runtime, so resolve the icon there instead of round-tripping through the shell title. The lock stays `.auto`, so a later command in the same tab still claims the slot, exactly as for a hand-typed agent.
onevclaw
left a comment
onevclaw
left a comment
There was a problem hiding this comment.
The new-tab path correctly applies the Agent Profile runtime icon while preserving the .auto lock, but the successful split path is currently missed.
launchAgentProfile returns immediately after creating a split in WorktreeTerminalState.swift, before reaching the runtime-icon update used by the new-tab path. Because the split becomes the focused surface and its env … OSC 2 title is not recognized by CommandIconMap, the containing tab can retain its previous icon. I reproduced this by starting with @asset:Git and launching a Codex Profile into a split: the icon remained @asset:Git instead of changing to the profile runtime icon.
Please apply the resolved icon to the split's containing tab before returning, while continuing to respect user/script locks, and add coverage for both .auto and locked split cases.
The terminal documentation should also be narrowed slightly: Profile commands only start with env when launch-scoped environment tokens exist, and only a later recognized command overrides the automatic icon.
onevclaw - an assistant to @onevcat
The split placement path returned right after creating the surface, before the runtime-icon update the new-tab path does. The split becomes the focused surface, and its `env …` title is not recognised by CommandIconMap, so the containing tab kept whatever icon it had — reproducibly `@asset:Git` when a Codex profile was launched into a split from a Git-branded tab. Apply the resolved icon through applyResolvedIcon before returning: it already guards focus and the icon lock, so `.user` and `.script` claims are untouched and the slot stays `.auto` for a later recognised command. launchTabIcon now returns TabIconSource? instead of folding an unmatched runtime into "terminal": on the split path that fallback would have overwritten the tab's existing icon. The new-tab call site keeps the glyph as its default. Docs narrowed accordingly: the `env` prefix appears only when the profile sets launch-scoped environment variables, and only a later *recognised* command takes the slot back.
|
@onevclaw Good catch on the split path — fixed in d1728a6. One adjacent change. |
|
@onevclaw Can you please verify the fix again? I can indeed reproduce this issue so obviously it is true. Please check and see the new fixes addressed your previous concerns. |
|
Rechecked on d1728a6. The split path now applies the resolved runtime icon to the newly focused split's containing tab before returning. Going through The optional icon result also avoids replacing an existing split-tab icon with the generic terminal glyph if a future runtime has no mapping; the new-tab path retains its deliberate fallback. The added tests cover the automatic split rebrand plus both locked cases. I ran
|
|
@verbaux Nice catch! Thank you for the fix. |
3 participants
Launching an agent from the Agents menu leaves the tab wearing the generic terminal glyph, while typing
claudeby hand in the same worktree shows the Claude Code brand icon.launchAgentProfilecreates the tab with a hardcodedicon: "terminal"and leaves the rest toCommandIconMap, which resolves an icon from the first whitespace token of the command in the OSC 2 title. Since 053/006 the launch command isenv CLAUDE_CONFIG_DIR='…' claude, so that token isenv. It matches nothing, and perCommandIconMap's contract an unmatched token deliberately leaves the existing icon untouched — so the placeholder stays for the life of the tab.The launch path already knows its runtime, so it resolves the brand icon directly instead of round-tripping through the shell title.
iconLockstays.auto, so a later command in the same tab still claims the slot, exactly as it does for a hand-typed agent.A profile's custom SF Symbol is deliberately out of scope: it isn't part of
AgentProfileLaunchPlan, anddocs/components/agent-profiles.mdalready states that live panes show the icon of the process Prowl actually detects.Test plan
make build-app— 0 errors, 0 warningsWorktreeTerminalStateAgentProfileTests— 5/5; reverting the one-line change failslaunchCreatesTheTabWithTheRuntimeIcon()make check— cleanNotes
createTabcall (and keeps the hardcoded glyph). Happy to rebase whenever it lands.CommandIconMapcould skip a leadingenv VAR=…prefix, so a hand-typedenv FOO=1 clauderesolves too.