[Bug]: Claude adapter renders SDK 'command_lifecycle' notifications as ✗ Work Log errors, making healthy threads read as corrupt #6093

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. Start a thread in T3 Code (Alpha) with the Claude provider (claudeAgent).
2. Have the agent invoke any slash command / skill (anything that runs through the Claude Code CLI's command mechanism — in my case skills like handoff and validate).
3. Open the thread's Work Log.

Expected behavior

command_lifecycle is routine bookkeeping from the Claude Agent SDK — a started and a completed notification pair for each command invocation. The adapter should either consume these silently or show them as neutral lifecycle info. A successfully completed command should never be styled as a failure.

Actual behavior

The desktop adapter does not recognize the command_lifecycle message type, downgrades each one to a runtime.warning, and the Work Log renders every warning with a red ✗ and the raw payload text (which the UI also truncates mid-field, e.g. a dangling · state:). A thread that ran five commands accumulates ten ✗ entries. To the user this reads as thread corruption — I initially abandoned a healthy thread because of it. The thread's provider log contains zero runtime.error events; every flagged command completed normally.

Impact

Minor bug or occasional failure

(Cosmetic at the data level, but it misleads users into abandoning healthy threads, so filing it a notch above cosmetic.)

Version or commit

T3 Code (Alpha) 0.0.33

Environment

macOS (Darwin 25.6.0, Apple Silicon M5 Pro), Claude Code CLI 2.1.227, provider claudeAgent (Claude Max auth), model claude-fable-5

Logs or stack traces

# Native SDK event as received (well-formed):
[2026-08-11T03:56:03.206Z] NTIVE: {"event":{"kind":"notification","provider":"claudeAgent",
  "method":"claude/command_lifecycle",
  "payload":{"type":"command_lifecycle","command_uuid":"4cd8e8a3-df7a-425d-b6c9-4053abc0b8fd",
             "state":"started","session_id":"6e81554e-5cff-4b37-8a39-f3a9051ac234"}}}

# Adapter's canonical translation one tick later — downgraded to a warning:
[2026-08-11T03:56:03.207Z] CANON: {"type":"runtime.warning","provider":"claudeAgent",
  "payload":{"message":"Claude SDK message 'command_lifecycle' — command_uuid: 4cd8e8a3-df7a-425d-b6c9-4053abc0b8fd · state: started",
             "detail":{"type":"command_lifecycle","state":"started", ...}}}

# Matching completion for the same command_uuid, also warned:
[2026-08-11T03:57:08.184Z] NTIVE: ... "payload":{"type":"command_lifecycle",
  "command_uuid":"4cd8e8a3-df7a-425d-b6c9-4053abc0b8fd","state":"completed", ...}

# That thread's totals: 10 runtime.warning (all command_lifecycle, 5 started/completed pairs), 0 runtime.error.

Workaround

None needed for data integrity — the ✗ entries are safe to ignore and the thread remains usable. The cost is purely that users can't tell these apart from real failures.

Possibly related version-skew symptoms observed in the same sessions, already tracked separately: #5583 (structuredContent: null MCP violation from void preview tools) and #3713 (preview_snapshot failures).