Creating a New Adapter for Amp Project

Summary

hi amp, how's it going?

Now I have everything I need. Let me look at the Pi adapter too since it's the newest and likely the cleanest pattern to follow (it also reads JSON files like Amp):

Now I have all the context. Let me create everything in the worktree — project file, fixture, stub adapter, and failing tests:

Now let me create the fixture, stub adapter, register it, and write failing tests — all in the worktree:

Now create the empty thread fixture (edge case):

Now add the history.jsonl fixture:

Editedagent.ts

Now update types and config, create the stub adapter, and register it:

Editedtypes.ts

Editedconfig.ts

Ran

Now create the stub adapter:

Editedindex.ts

Now register it:

Editedindex.ts

Ran

Now build shared types and add the Amp adapter to the test file:

Editedadapters.test.ts

Now add the Amp adapter to the test file — add the import and fixture-backed adapter:

Editedadapters.test.ts

Now let's also add a background fixture for the Amp adapter. Let me check the existing pattern at the bottom of the backgroundFixtures object:

Editedadapters.test.ts

Now let's add the amp background fixture. Let me find the closing bracket of backgroundFixtures:

Ran

Now let's run the tests to see them fail:

9 failing tests against the stub, exactly as expected. All existing tests still pass. Here's the summary:

Created in the feat/amp-adapter worktree:

docs/projects/amp-adapter.md — Project plan with phases
packages/shared/src/agent.ts — Added 'amp' to AgentId
cli/src/types.ts — Added 'amp' to CLI AgentId
cli/src/config.ts — Added amp storage path (~/.local/share/amp)
cli/src/adapters/amp/v1.ts — Stub adapter with TODO implementations
cli/src/adapters/index.ts — Registered AmpAdapter
cli/test/fixture/amp/ — Fixtures (normal thread with tool calls/thinking, empty thread, history.jsonl)
cli/test/core/adapters.test.ts — Added Amp to adapter contract tests + background fixtures

9 tests failing against the stub — ready to implement. Want me to start filling in the adapter?

Yep! Also, make sure you're staging changes in incremental, reversible commits

The user wants me to implement the adapter and commit incrementally. Let me start by committing the current stub + types + fixtures, then implement the adapter.

Let me first commit the types/config changes, then the stub + registration, then the fixtures + tests, and finally the implementation.

Actually, let me think about good commit boundaries:

Types + config (shared types, CLI types, config storage path)
Stub adapter + registration
Fixtures + test additions
Implementation

Let me start with commit 1.

Ran

Let me commit the foundation first, then implement and commit incrementally.

Ran

Good, 3 clean commits. Now let me implement the adapter:

Ran

Now let's run the tests:

Ran

All 133 tests pass, including all 9 Amp adapter tests. Let me also run the full CLI test suite to be safe:

Ran

The one failure is a pre-existing flaky OpenCode test, not related to our changes. Let me verify:

Ran

Confirmed — that test fails on main too. Not our issue. Let me commit the implementation:

Ran

Done! 4 incremental, reversible commits:

Types + config + project plan — adds 'amp' AgentId and storage path
Stub adapter + registration — wires up the empty adapter
Fixtures + failing tests — golden fixtures and 9 failing contract tests
Full implementation — all 9 tests pass, 0 regressions

The adapter handles all Amp content block types (text, thinking, tool_use, tool_result), extracts model info, supports getCurrentTraceHint via session.json, and has live subscribe via fs.watch. Ready for manual testing or PR!

Okay awesome. How is the amp adapter different than others? How does amp store sessions differently, and perhaps, how should we modiy our frontend to make sure things like interruptions, attachments and other transforms are correctly handled?

The user wants to understand how Amp's data format differs from other adapters and what frontend implications there might be. Let me analyze the Amp thread format more deeply and compare it with other adapters, then look at the frontend to understand how traces are rendered.

Let me look at:

The Amp thread format in more detail (especially edge cases like interruptions, attachments, images)
How the sync/transform layer works (cli/src/services/api.ts)
The frontend rendering of traces

Ran

Great question. Let me dig into the Amp format differences and the frontend rendering pipeline.

"The transformation of CLI events to API messages and parts for sync upload happens at the sync boundary in the CLI's API service. The process involves scrubbing secrets, mapping internal `TraceEvent` types to API `role` and `parts`, and normalizing the content using `PartType` from the shared package.\n\nRelevant files:\n- [cli/src/services/api.ts#L277-L356](file:///Users/tarunsachdeva/code/traces/cli/src/services/api.ts#L277-L356) — Contains `buildMessagePayload` and `buildMessagePayloadForEvent` which handle the core transformation of individual events.\n- [cli/src/services/api.ts#L358-L362](file:///Users/tarunsachdeva/code/traces/cli/src/services/api.ts#L358-L362) — `buildMessagePayloads` transforms an array of events into a batch of API payloads.\n- [cli/src/services/api.ts#L222-L229](file:///Users/tarunsachdeva/code/traces/cli/src/services/api.ts#L222-L229) — `normalizeParts` ensures part content is sanitized before upload.\n- [cli/src/services/scrub-secrets.ts#L88-L90](file:///Users/tarunsachdeva/code/traces/cli/src/services/scrub-secrets.ts#L88-L90) — `scrubEvent` is called during transformation to redact sensitive information before it reaches the API.\n\n**Function Signatures:**\n- `function buildMessagePayload(trace: TraceMetadata, event: TraceEvent): SyncMessagePayload | null`\n- `export function buildMessagePayloadForEvent(trace: TraceMetadata, event: TraceEvent): SyncMessagePayload | null`\n- `function buildMessagePayloads(trace: TraceMetadata, events: TraceContent['events']): SyncMessagePayload[]`\n- `function normalizeParts(parts?: Array<{ type: string; content: unknown }>): Array<{ type: string; content: unknown }> | undefined`\n- `function scrubEvent(event: TraceEvent): TraceEvent`"

"The frontend uses a modular architecture for rendering trace messages, centered around a router component that selects the appropriate display for each message type and tool call.\n\n- **`MessageItem`**: The main router component that switches between different message types based on the `@traces/shared` `PartType` constants.\n- **`ToolCallRouter`**: A sub-router within `MessageItem` that handles rendering specific tool calls (e.g., `read`, `edit`, `terminal_command`) and matching them with their `tool_result`.\n- **`AssistantMessage` / `UserMessage`**: Basic components for displaying text content using a `Markdown` component.\n- **`ThinkingMessage`**: Handles `agent_thinking` parts, displaying them within an `ExpandableMessage` with duration information.\n- **`MessageList`**: Orchestrates the rendering of messages, manages the `SessionProvider` (which tracks `toolResults`), and handles message grouping/accordions.\n\n### Relevant files:\n- [frontend/components/messages/MessageItem.tsx#L227-L255](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/MessageItem.tsx#L227-L255) — Main message type router.\n- [frontend/components/messages/MessageItem.tsx#L72-L215](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/MessageItem.tsx#L72-L215) — `ToolCallRouter` for specific tools.\n- [frontend/components/messages/AssistantMessage.tsx#L6-L18](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/AssistantMessage.tsx#L6-L18) — Renders `agent_text`.\n- [frontend/components/messages/UserMessage.tsx#L12-L24](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/UserMessage.tsx#L12-L24) — Renders `user_message`.\n- [frontend/components/messages/ThinkingMessage.tsx#L36-L60](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/ThinkingMessage.tsx#L36-L60) — Renders `thinking` parts.\n- [frontend/components/messages/MessageList.tsx#L56-L308](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/MessageList.tsx#L56-L308) — Message collection rendering and `tool_result` mapping.\n- [frontend/components/messages/tools/ToolResult.tsx#L15-L23](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/tools/ToolResult.tsx#L15-L23) — Shared UI for displaying tool output.\n- [frontend/components/messages/tools/DefaultToolMessage.tsx#L12-L28](file:///Users/tarunsachdeva/code/traces/frontend/components/messages/tools/DefaultToolMessage.tsx#L12-L28) — Fallback for tool calls without specific components."

hi!

Ran

Now let me check what Amp-specific content blocks look like that differ from Claude Code — especially interruptions, images/attachments, and the tool_result structure:

Now I have the full picture. Here's how Amp differs and what it means for the frontend:

How Amp Stores Sessions Differently

1. Single JSON file per thread (not JSONL) Other adapters use JSONL (one event per line) or SQLite. Amp uses a single threads/T-{uuid}.json with a messages array — the whole file is rewritten on each update. This means we parse the entire file each time (no tail-scanning optimization like Claude Code).

2. Rich tool_result structure Claude Code tool results are simple content blocks. Amp wraps them in { run: { status, result, progress } } with structured result objects (not just strings). Our adapter serializes run.result to JSON, which works but means the frontend sees JSON blobs rather than pre-formatted output.

3. Interruptions are state.type: "cancelled" or "streaming" Claude Code marks interruptions with a [Request interrupted by user] text message. Amp uses:

state.type: "cancelled" on assistant messages
state.type: "streaming" for in-progress (thread read while still running)
tool_result blocks with run.status: "cancelled"

The frontend's isInterruptionMessage() only checks for Claude Code's [Request interrupted...] pattern and OpenCode's (no error message) error parts — it won't detect Amp interruptions.

4. Rich env metadata Amp stores detailed environment info: git repo URL, branch, SHA, OS, CPU architecture, client version, and workspace tree URIs. Other adapters just store a project path string. We could surface this richer context.

5. No toolName on tool results Amp's tool_result blocks don't include the tool name — only the toolUseID. Our adapter currently emits toolName: '' for results. The frontend's ToolCallRouter matches results to calls by callId, so this works, but tools that key off toolName in the result might show fallback rendering.

Frontend Changes Worth Considering

Issue	Impact	Fix
Interruptions invisible	Amp cancelled turns show as blank/empty messages	Add Amp's `cancelled` state detection to adapter (emit an error event) or teach frontend about it
Tool result is JSON blob	Read/Edit results show as raw `{"absolutePath":..., "content":...}` instead of formatted output	Frontend's `parseRawResult` already handles JSON with `contents` field (Cursor format) — could extend to handle Amp's `result.content` field
No agent color	`getAgentColor('amp')` returns the default muted color	Add an Amp-specific color to the theme
Streaming threads	Active threads have `state.type: "streaming"` messages with incomplete content	Adapter should skip or handle these gracefully

The most impactful quick wins would be handling interruptions in the adapter and adding an agent color. Want me to tackle any of these?

Yeah for sure. Let's complete the adapter, and are there any new tests you think we should add here for amp?

The user wants me to:

Handle the Amp-specific edge cases (interruptions, streaming, tool result formatting, agent color)
Add new Amp-specific tests for these edge cases

Let me plan what to do:

Adapter changes:
- Handle state.type: "cancelled" assistant messages — emit an error event for interruptions
- Handle state.type: "streaming" — skip incomplete messages or handle gracefully
- Handle tool_result with run.status: "cancelled" — emit with error status
- Populate toolName on tool_result by tracking pending tool calls (like Claude Code adapter does)
- Extract the actual content string when tool results have nested structured output
Config/theme:
- Add agent color for Amp in the TUI theme
Tests to add:
- Interrupted/cancelled thread (assistant with state.type: "cancelled", tool_result with run.status: "cancelled")
- Streaming/incomplete messages (should be skipped or handled)
- Tool result with nested structured result (should extract output nicely)
- Empty messages array
- Tool name resolution from pending tool calls
- Thread with no title (falls back to first user message)
- Thread with title

Now I'm looking at the theme file to start making these changes.

[
  "/Users/tarunsachdeva/code/traces/cli/src/tui/theme.ts:33:export function getAgentColor(agentId: AgentId): string {",
  "/Users/tarunsachdeva/code/traces/cli/src/tui/hooks/useAppState.ts:35:import { colors, getAgentColor } from '../theme.js';",
  "/Users/tarunsachdeva/code/traces/cli/src/tui/components/ListView.tsx:12:import { colors, getAgentColor } from '../theme.js';",
  "/Users/tarunsachdeva/code/traces/cli/src/tui/components/ListView.tsx:102:fg={state.isSelected() ? colors.text : getAgentColor(item.trace.agentId)}",
  "/Users/tarunsachdeva/code/traces/cli/src/tui/components/ListView.tsx:165:fg={state.isSelected() ? colors.text : getAgentColor(item.trace.agentId)}",
  "/Users/tarunsachdeva/code/traces/cli/src/tui/components/ListView.tsx:262:fg={state.isSelected() ? colors.text : getAgentColor(item.trace.agentId)}",
  "/Users/tarunsachdeva/code/traces/cli/test/tui/theme.test.ts:2:import { getAgentColor, colors } from '../../src/tui/theme.js';",
  "/Users/tarunsachdeva/code/traces/cli/test/tui/theme.test.ts:4:describe('getAgentColor', () => {",
  "/Users/tarunsachdeva/code/traces/cli/test/tui/theme.test.ts:8:expect(getAgentColor('claude-code')).toBe('#f97316');",
  "/Users/tarunsachdeva/code/traces/cli/test/tui/theme.test.ts:17:expect(getAgentColor('opencode')).toBe('#22c55e');",
  "/Users/tarunsachdeva/code/traces/cli/test/tui/theme.test.ts:26:expect(getAgentColor('cursor')).toBe('#8b5cf6');",
  "/Users/tarunsachdeva/code/traces/cli/test/tui/theme.test.ts:35:expect(getAgentColor('windsurf')).toBe(colors.muted);",
  "/Users/tarunsachdeva/code/traces/cli/test/tui/theme.test.ts:44:expect(getAgentColor('manual')).toBe(colors.muted);"
]

Let me check the TUI theme and then implement everything together.

Now let me look at an existing adapter and the registry to understand the full pattern:

[
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:8:case \"claude-code\":",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:10:case \"gemini-cli\":",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:12:case \"codex\":",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:25:agent: \"claude-code\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:33:agent: \"codex\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:41:agent: \"gemini-cli\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:49:agent: \"claude-code\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:65:agent: \"codex\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:82:agent: \"gemini-cli\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/HeroImage.tsx:95:agent: \"claude-code\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/og/OgAgentLogo.tsx:15:\"claude-code\": \"claude-code-logo.png\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/og/OgAgentLogo.tsx:17:codex: \"codex-logo-light.png\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/og/OgAgentLogo.tsx:20:\"gemini-cli\": \"gemini-cli-logo-light.png\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:6:| \"claude-code\"",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:12:| \"gemini-cli\"",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:13:| \"codex\"",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:32:\"claude-code\": \"/agent-logos/claude-code-logo.svg\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:37:codex: {",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:38:light: \"/agent-logos/codex-logo-light.svg\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:39:dark: \"/agent-logos/codex-logo-dark.svg\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:49:\"gemini-cli\": {",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:50:light: \"/agent-logos/gemini-cli-logo-light.svg\",",
  "/Users/tarunsachdeva/code/traces/frontend/components/ui/AgentLogo.tsx:51:dark: \"/agent-logos/gemini-cli-logo-dark.svg\","
]

"All 5 changes are applied and the project compiles cleanly:\n\n1. **Pending tool calls** — `pendingToolCalls` map stores `callId -> toolName` on `tool_use`, looked up on `tool_result`\n2. **Interruptions** — cancelled assistant messages emit an `ErrorEvent` with `\"Request interrupted by user\"`\n3. **Cancelled tool results** — `run.status === 'cancelled'` → status `'error'`, output `\"(cancelled)\"`\n4. **Skip streaming** — messages with `state.type === 'streaming'` are skipped entirely\n5. **Better output extraction** — checks `result.content` and `result.output` strings before falling back to `JSON.stringify`"

Good. Now I have the full picture. Let me implement all the changes across the worktree. I'll do this in parallel tasks:

"All four changes applied:\n\n1. **`theme.ts`** — Added `'amp': '#00d9ff'` to the agents color map\n2. **`AgentLogo.tsx`** — Added `\"amp\"` to `AgentId` union, `amp: null` to `AGENT_LOGOS`, and `amp: \"Amp\"` to `AGENT_NAMES` (not added to `AGENT_IDS_WITH_LOGOS`)"

Good. Now I have the full picture. Let me implement all the changes across the worktree. I'll do this in parallel tasks:

Ran

All three tasks done. Let me verify everything passes:

Ran

All 141 tests pass (9 original + 8 new Amp-specific = 17 Amp tests total). Let me also run the full suite:

Ran

554 pass, 0 fail (even the flaky OpenCode test passed this time). Now let me commit incrementally:

Ran

7 clean, incremental commits. 554 tests pass, 0 failures. Here's what we added in the last round:

Adapter hardening:

toolName tracking — pending tool call map resolves toolName on tool_result (was empty string)
Interruptions — state.type: "cancelled" emits an error event ("Request interrupted by user")
Streaming skip — state.type: "streaming" messages are dropped entirely
Cancelled tool results — run.status: "cancelled" → error status + "(cancelled)" output
Better output extraction — checks result.content and result.output strings before JSON.stringify fallback

8 new edge case tests covering all the above + title extraction, empty threads, and cursor deduplication

UI support:

TUI: cyan #00d9ff agent color for Amp
Frontend: AgentLogo placeholder (ready for an SVG when available)

Attached here: /Users/tarunsachdeva/Downloads/amp-mark-dark.svg /Users/tarunsachdeva/Downloads/amp-mark-light.svg

Wanna incorporate them?

"### Description\n\n**Colors**\n- **Main file:** All paths are white (`#FFFFFF`).\n- **Reference file:** All paths are black (`#000000`).\n\n**Shape**\n- The logo consists of four distinct geometric paths.\n- It features three nested, chevron-like shapes (shards) and one diagonal bar.\n- The design is abstract, sharp-angled, and oriented diagonally, suggesting motion or an \"A\" form.\n\n### Suitability as a 16-24px Agent Icon\nThe logo is **highly suitable** for small-scale rendering:\n- **Scalability:** The geometric, bold shapes will remain legible at 16px and 24px.\n- **Proportions:** The `viewBox` of `28 28` is nearly 1:1 with the target sizes, minimizing sub-pixel rendering issues.\n- **Simplicity:** There are no fine details or thin lines that would disappear when downsampled.\n- **Contrast:** The solid fills (white or black) provide high contrast against typical UI backgrounds."

Readv1.ts

Ran

EditedAgentLogo.tsx

Now add Amp to the list of agents with logos:

Ran