feat: add AgentAdapter abstraction with Codex CLI support

[ayeo]

Description

Replace hardcoded Claude Code transcript parsing with an extensible AgentAdapter trait and registry. Each AI coding agent gets its own adapter for event mapping, file change extraction, and transcript record parsing. Adds full Codex CLI support.

What's included

• AgentAdapter trait with ClaudeCode, Codex, and Default adapters in tracevault-core
• Codex transcript parsing — handles response_item/message, custom_tool_call, event_msg, apply_patch file changes from transcript chunks
• CLI changes — protocol v2, --agent flag for stream command, Codex-compatible hook response format
• tracevault init --agent codex — installs Codex hooks in .codex/hooks.json
• AgentBadge component — shows agent type with icon on session list and detail views
• Cleanup — removed old hardcoded extract_file_change/is_file_modifying_tool from streaming.rs
• 34 adapter tests, UTF-8 safe truncation, code review fixes

How it works

The server resolves the adapter from sessions.tool column (set by CLI via --agent flag). During ingestion (stream.rs), the adapter extracts tokens and file changes. During display (session_detail.rs, traces_ui.rs), it parses transcript chunks into TranscriptRecords for the frontend.

Codex file modifications come exclusively through transcript chunks (custom_tool_call with apply_patch), not through hook ToolUse events — the adapter handles this via extract_file_changes_from_transcript.

Checklist

• Tests added or updated
• cargo fmt passes
• cargo clippy passes

🤖 Generated with Claude Code

[hashedone]

Review notes

Thanks for this — the adapter abstraction is clean and the capability-flag pattern is the right approach. A few things worth addressing before merge, ranging from a potential silent data loss to minor maintenance notes.

---

🟡 Medium: chunk_index collision between transcript chunks and synthetic tool events

In service/stream.rs, when provides_transcript_file_changes() is true (Codex), synthetic tool events are inserted with event_index: chunk_index:

event_index: chunk_index,  // reusing transcript chunk index

The events table has UNIQUE(session_id, event_index) with ON CONFLICT DO NOTHING. If a Codex session also receives hook ToolUse events whose event_index values overlap with transcript chunk indices, the second insert is silently dropped. There is no namespace separation between the two index spaces. This does not affect CC (gated by provides_transcript_file_changes = false), but for Codex sessions it could silently lose events without any error.

Suggestion: either offset synthetic event indices (e.g. use a separate counter namespace), or assert they come from a different range.

---

🟡 Medium: AgentAdapterRegistry constructed per hook call in CLI

In crates/tracevault-cli/src/commands/stream.rs:

let registry = AgentAdapterRegistry::new();
let adapter = registry.get(agent);

This constructs a new registry (allocating all adapters) on every hook invocation — PostToolUse fires on every tool call. The allocation is cheap but unnecessary. Consider constructing just the needed adapter directly, or passing the agent name through to a shared/static registry.

---

🔵 Low: Codex hooks.json wraps entries under a "hooks" key — needs spec verification

In CodexAdapter::install_hooks:

config_obj.insert("hooks".to_string(), hooks_json());

This writes {"hooks": {"PostToolUse": [...]}} to .codex/hooks.json. But based on the Codex docs, hooks are defined at the top level of hooks.json — the file contents should be {"PostToolUse": [...]} directly, not wrapped under a "hooks" key. Worth verifying against the current Codex hook spec before shipping, otherwise the hooks may silently not fire.

---

🔵 Low: store_response variable reused as file-change extraction gate

let store_response = adapter.is_file_modifying(tool_name);
// ...
if store_response {
    // file change extraction

store_response was semantically named for "should we persist the tool_response blob" but is reused as the gate for file change extraction. For CC these happen to be the same tool set (Write/Edit/Bash), but the coupling is implicit. A future adapter that has a file-modifying tool with large/binary output would need to override is_file_modifying to false to avoid storing the blob — which would also skip file change extraction. Worth separating into two distinct capability queries.

---

🔵 Low: CC protocol v1 fallback fragility

let agent_name = tool.as_deref().unwrap_or("claude-code");

This works correctly for v1 (where tool is absent). Worth a comment noting that if a future CC version sends v2 without tool: "claude-code", it would fall through to DefaultAdapter and lose all token/file extraction silently. The CLI sets tool explicitly so this is safe today, but the silent fallback is worth documenting.

---

🔵 Low: Hardcoded Codex system prompt XML tags — maintenance drift risk

const CODEX_SYSTEM_PROMPT_TAGS: &[&str] = &[
    "<user_instructions>",
    "<environment_context>",
    ...

These are sourced from openai/codex protocol.rs. If Codex adds or renames tags in a future release, this filter will either pass system prompts through (display noise) or incorrectly filter legitimate user messages. A comment noting the Codex source file and version where these were verified would help future maintainers know when to re-check.