feat(opencode): rich handoff with tool calls, diffs, model, and token usage

[dhruvkej9]

Problem

The OpenCode parser produced bare-bones handoffs — only plain text messages, no tool calls, no file modifications, no model info, no token usage. Starting in OpenCode and handing off to Codex (or any other tool) lost almost all context about what actually happened.

Before (old handoff):

## Recent Conversation
### User
"Add a subtract function..."
### Assistant
"Implemented it."
## Files Modified
(none)

After (this PR):

## Session Overview
| Model | gpt-5.3-codex |
| Tokens Used | 9,828 in / 708 out |
| Cache Tokens | 45,184 read |
| Thinking Tokens | 118 |
| Files Modified | 2 |

## Tool Activity
### Shell (1 calls)
> `$ node index.js`
> Exit: 0
> 5
> 6
> -1

### Edit (2 calls)
> **math.js** (+5 -0 lines)
> ```diff
> +function subtractTwoNumbers(a, b) {
> +  return a - b;
> +}
> ```

### Glob (2 calls)
- `**/math.js` — 1 files
- `**/index.js` — 1 files

### Read (2 calls)
- math.js
- index.js

## Files Modified
- math.js
- index.js

What changed

Rewrote src/parsers/opencode.ts to extract all available data from OpenCode's SQLite database and JSON storage.

New data extracted:

• Model and provider info (e.g. gpt-5.3-codex, openai)
• Token usage breakdown (input, output, reasoning, cache read/write)
• Thinking tokens from OpenAI o-series models
• Active time tracking from first-to-last message timestamps
• Shell commands with exit codes and stdout
• Full apply_patch diffs with file stats (+N -M)
• Glob results with match counts
• Read operations with file paths
• Generic tool calls (MCP, web_search, web_fetch)
• File modification tracking from patch parts and shell redirects
• Todo extraction from the todo table
• Reasoning highlights from reasoning parts

Technical approach:

• Two-pass SQLite extraction: first collect parts, then classify and summarize each tool call
• Uses the same SummaryCollector pattern as Claude and Codex parsers
• Proper structured data (ShellSampleData, EditSampleData, ReadSampleData, GlobSampleData) for category-aware rendering
• Zod 4 compatibility fix (z.record(key, value) instead of z.record(value))
• Legacy JSON fallback for older OpenCode versions

Testing

Ran 5 messages in OpenCode (opencode run) with mixed tool calls:

1. glob — find files
2. read — read file contents
3. apply_patch — create/edit files
4. bash — run node to verify

Handoff to Codex via continues inspect <session-id> produces the full rich context shown above.

735 lines added, 119 removed in src/parsers/opencode.ts.

---

Review all of them with eye of John Carmack-like simplicity with elegeance approach and apply the one only if required

Greptile Summary

This PR rewrites src/parsers/opencode.ts to extract rich context from OpenCode sessions — tool calls (bash, glob, read, apply_patch, web_search), session metadata (model, token usage, cache, thinking tokens), todos, and reasoning highlights — producing the kind of handoff document that actually helps the receiving tool resume work intelligently. The core approach (two-pass SQLite extraction + SummaryCollector) fits the established pattern. There are three correctness issues that need fixes before merge:

• Double JSON.parse / Zod bypass (P1): Both extractToolDataFromParts and extractToolDataFromJsonParts validate raw data through safeParse, then immediately re-parse the same string with as Record<string, unknown>, discarding the validated result entirely. The Zod check becomes a gate that passes/fails but its output is thrown away.
• Missing trimMessages() (P1): extractOpenCodeContext calls allMessages.slice(-N) directly instead of trimMessages() from parser-helpers.ts. A session ending with a burst of assistant messages will produce a handoff with zero user context.
• Dead code accumulation (P2): TOOL_NAME_MAP (1-to-1 identity map, only used in the default branch), trackPatchFiles (defined but never called — its logic is duplicated inline in both apply_patch cases), an unused description variable in the bash handler, and an unused withResult import.

Confidence Score: 3/5

• Three targeted fixes required before merge: two Zod-bypass bugs and one trimMessages omission.
• The architecture is sound and follows established patterns. The two double-parse bugs are real correctness issues (validated data discarded, raw cast used instead), and the missing trimMessages() can produce a handoff with no user messages. All three have simple, mechanical fixes. Dead code issues are cleanup but not blockers.
• src/parsers/opencode.ts — specifically lines 509–512, 712–715, and 1123.

Important Files Changed

Filename	Overview
src/parsers/opencode.ts	Major rewrite adding rich tool extraction, session notes, and todo support. Three correctness issues: double JSON.parse defeating Zod validation in both SQLite and JSON paths, and missing trimMessages() call that can produce user-less handoffs. Also contains dead code (TOOL_NAME_MAP, trackPatchFiles, unused description variable, unused withResult import).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[extractOpenCodeContext] --> B{hasSqliteDb?}
    B -- yes --> C[openDb]
    C --> D[extractToolDataFromParts]
    C --> E[extractSessionNotesFromSqlite]
    C --> F[extractTodos]
    C --> G[readConversationMessagesFromSqlite]
    D --> D1[patchParts loop - file tracking]
    D --> D2[partRows loop - tool switch]
    D2 --> D3{tool type}
    D3 -- bash --> D4[shellSummary + trackShellFileWrites]
    D3 -- glob --> D5[globSummary]
    D3 -- read --> D6[fileSummary]
    D3 -- apply_patch --> D7[countDiffStats + trackFile]
    D3 -- web_search --> D8[searchSummary]
    D3 -- web_fetch --> D9[fetchSummary]
    D3 -- default --> D10[mcpSummary]
    B -- no / empty --> H[readConversationMessagesFromJson]
    H --> I[extractToolDataFromJsonParts]
    H --> J[extractSessionNotesFromJson]
    G --> K{allMessages empty?}
    K -- yes --> H
    K -- no --> L[allMessages.slice - SHOULD USE trimMessages]
    L --> M[generateHandoffMarkdown]
    M --> N[SessionContext]

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 509-512

Comment:
**Zod validation discarded — double JSON.parse**

`row.data` is parsed and validated through `SqlitePartDataSchema.safeParse`, but then immediately re-parsed with a raw cast on line 512, completely discarding the validated result. This makes the Zod check a no-op and re-introduces the risk of malformed data crashing execution downstream.

```suggestion
      const partDataResult = SqlitePartDataSchema.safeParse(JSON.parse(row.data));
      if (!partDataResult.success) continue;
      const part = partDataResult.data as Record<string, unknown>;
```

Same pattern is repeated in `extractToolDataFromJsonParts` at line ~715.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 712-715

Comment:
**Same double JSON.parse in JSON path**

Same bug as in the SQLite path at line 509–512. `partContent` is validated through `OpenCodePartSchema.safeParse` but then re-parsed with a raw cast. Use the validated result:

```suggestion
        const partResult = OpenCodePartSchema.safeParse(JSON.parse(partContent));
        if (!partResult.success) continue;
        const part = partResult.data as Record<string, unknown>;
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 1123

Comment:
**`trimMessages()` not used — handoff may have zero user messages**

This uses a raw `.slice()` instead of the required `trimMessages()` helper from `parser-helpers.ts`. If the last N messages are all assistant messages, the handoff document loses all user context. The `trimMessages()` helper guarantees at least one user message is included.

```suggestion
  const trimmed = trimMessages(allMessages, resolvedConfig.recentMessages);
```

Also requires adding the import: `import { extractRepoFromCwd, homeDir, trimMessages } from '../utils/parser-helpers.js';`

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 444-459

Comment:
**`TOOL_NAME_MAP` is effectively dead code**

The map is 1-to-1 (each key maps to the identical string) and `toolName` is only used in the `default` MCP branch. The switch statement dispatches on `String(part.tool)` directly, so the map never transforms anything. Delete it and replace the `default` branch usage with `String(part.tool)` directly — which is already what `partTool` contains on line 619.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 464-470

Comment:
**`trackPatchFiles` is dead code**

This function is never called. The `apply_patch` case in both `extractToolDataFromParts` and `extractToolDataFromJsonParts` duplicates the regex logic inline. Either delete this function and keep the inline code, or call it from both `apply_patch` cases and remove the duplication. Currently it just pads the file.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 530

Comment:
**Unused variable `description`**

`description` is assigned but never referenced. Remove it.

```suggestion
          
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 36

Comment:
**`withResult` imported but never used**

`withResult` is imported from `tool-summarizer.ts` but not called anywhere in the file. Remove it from the import statement.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat(opencode): rich handoff with tool c..." | Re-trigger Greptile}

Greptile also left 3 inline comments on this PR.

[devin-ai-integration]

Devin Review found 9 potential issues.

[devin-ai-integration]

🔴 totalCost is accumulated but never stored in the returned SessionNotes object

In extractSessionNotesFromSqlite, totalCost is declared (line 813) and accumulated from each message's msgData.cost (line 847), but it is never assigned to the notes object that is returned. The cost data is silently discarded. The SessionNotes type at src/types/index.ts:230 also has no cost field, so this appears to be a partially-implemented feature where both the type update and the assignment were forgotten.

Prompt for agents

In src/parsers/opencode.ts, the extractSessionNotesFromSqlite function accumulates totalCost at line 813 and 847 but never assigns it to the notes object. Either:
1. Add a `cost?: number` field to the `SessionNotes` interface in src/types/index.ts (around line 242), and add `if (totalCost > 0) notes.cost = totalCost;` before the return statement at line 886 in src/parsers/opencode.ts.
2. Or remove the dead totalCost variable entirely (lines 813, 846-848) if cost tracking is not needed.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 Empty catch blocks with only comments violate the mandatory logger.debug convention

REVIEW.md and AGENTS.md both mandate: "Empty catch {} blocks fail the linter; use catch (err) { logger.debug(...) } instead." The PR introduces 9 catch blocks that contain only /* ignore */ comments and no logger.debug call (lines 359, 376, 501, 849, 867, 935, 939, 995, 1007). The existing code in the same file consistently uses logger.debug in catch blocks (e.g., src/parsers/opencode.ts:282, src/parsers/opencode.ts:300), so this is also inconsistent with the local code style.

Prompt for agents

In src/parsers/opencode.ts, replace all empty catch blocks that only have comments with catch blocks that call logger.debug. There are 9 instances at lines 359, 376, 501, 849, 867, 935, 939, 995, and 1007. Each should follow the pattern:
  catch (err) { logger.debug('opencode: <description of what failed>', err); }
For example, line 849 should become: catch (err) { logger.debug('opencode: failed to parse message data', err); }

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 Unused variable description assigned but never referenced

At line 530, const description = String(metadata.description || input.description || '') is assigned within the bash case of extractToolDataFromParts, but the variable is never used in the summary, data object, or anywhere else. This is likely a bug where the description was intended to be included in the shell summary or data payload but was forgotten.

Suggested change

const description = String(metadata.description || input.description || '');

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 Function trackPatchFiles is defined but never called (dead code)

The function trackPatchFiles at line 464 extracts file paths from patch text and tracks them via collector.trackFile(). However, it is never called anywhere in the file. The same logic is implemented inline within both extractToolDataFromParts (lines 576-577) and extractToolDataFromJsonParts (lines 765-766). This dead function adds confusion about the code's intent.

Suggested change

	function trackPatchFiles(patchText: string, collector: SummaryCollector): void {
	const fileMatches = patchText.match(/\*\*\* (?:Add|Update|Delete) File: (.+)/g) || [];
	for (const match of fileMatches) {
	const filePath = match.replace(/^\*\*\* (?:Add|Update|Delete) File: /, '');
	collector.trackFile(filePath);
	}
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 JSON fallback extractSessionNotesFromJson does not extract token usage or cost

The SQLite path extractSessionNotesFromSqlite accumulates tokenUsage, thinkingTokens, cacheTokens, and cost from message data. However, the JSON fallback extractSessionNotesFromJson (line 892) only extracts model and reasoning — it does not attempt to parse token or cost data from JSON message files. This means sessions parsed via the JSON fallback will always have incomplete SessionNotes compared to SQLite sessions. This may be intentional (JSON format may not include token data), but it's an asymmetry worth noting.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

📝 Info: JSON fallback switch statement missing web_search and web_fetch cases

The SQLite tool extraction path (extractToolDataFromParts, lines 595-613) has explicit case 'web_search' and case 'web_fetch' handlers with proper category tagging. The JSON fallback extractToolDataFromJsonParts (line 725) does not have these cases — web search/fetch tools fall through to the default MCP handler, which tags them with category: 'mcp' instead of 'search'/'fetch'. This creates an inconsistency in how the same tools are categorized depending on the storage backend. If downstream rendering uses the category field for display, web tools from JSON sessions will look different.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

📝 Info: Double JSON.parse on each part row in tool extraction

In both extractToolDataFromParts (lines 509-512) and extractToolDataFromJsonParts (lines 712-715), each part row's data is parsed twice: once for SqlitePartDataSchema.safeParse(JSON.parse(row.data)) validation, and then again with JSON.parse(row.data) as Record<string, unknown> for flexible access. The validated result from safeParse is discarded after the success check. This is a minor performance issue — the validated partDataResult.data could be used directly instead of re-parsing.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

📝 Info: SQLite context extraction opens only one DB handle for all operations

The refactored extractOpenCodeContext (line 1085) opens a single database handle and passes it to extractToolDataFromParts, extractSessionNotesFromSqlite, extractTodos, and readConversationMessagesFromSqlite. This is a good improvement over the old readMessagesFromSqlite which opened its own DB handle separately. The single-handle approach avoids multiple open/close cycles and ensures consistent reads within the same connection.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

📝 Info: Unused imports ReasoningStep, withResult, and type SqlitePartRow

ReasoningStep (line 8), withResult (line 41), and SqlitePartRow (line 18) are imported but never used in the file. While noUnusedImports is set to "error" in biome.json:26 and will be caught by the linter, these indicate possible incomplete implementation — e.g., withResult may have been intended for tool summary formatting, and ReasoningStep for structured reasoning data.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[greptile-apps]

Zod validation discarded — double JSON.parse

row.data is parsed and validated through SqlitePartDataSchema.safeParse, but then immediately re-parsed with a raw cast on line 512, completely discarding the validated result. This makes the Zod check a no-op and re-introduces the risk of malformed data crashing execution downstream.

Suggested change

	const partDataResult = SqlitePartDataSchema.safeParse(JSON.parse(row.data));
	if (!partDataResult.success) continue;
	// Cast to flexible type for tool data access
	const part = JSON.parse(row.data) as Record<string, unknown>;
	const partDataResult = SqlitePartDataSchema.safeParse(JSON.parse(row.data));
	if (!partDataResult.success) continue;
	const part = partDataResult.data as Record<string, unknown>;

Same pattern is repeated in extractToolDataFromJsonParts at line ~715.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 509-512

Comment:
**Zod validation discarded — double JSON.parse**

`row.data` is parsed and validated through `SqlitePartDataSchema.safeParse`, but then immediately re-parsed with a raw cast on line 512, completely discarding the validated result. This makes the Zod check a no-op and re-introduces the risk of malformed data crashing execution downstream.

```suggestion
      const partDataResult = SqlitePartDataSchema.safeParse(JSON.parse(row.data));
      if (!partDataResult.success) continue;
      const part = partDataResult.data as Record<string, unknown>;
```

Same pattern is repeated in `extractToolDataFromJsonParts` at line ~715.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Same double JSON.parse in JSON path

Same bug as in the SQLite path at line 509–512. partContent is validated through OpenCodePartSchema.safeParse but then re-parsed with a raw cast. Use the validated result:

Suggested change

	const partResult = OpenCodePartSchema.safeParse(JSON.parse(partContent));
	if (!partResult.success) continue;
	// Cast to flexible type for tool data access
	const part = JSON.parse(partContent) as Record<string, unknown>;
	const partResult = OpenCodePartSchema.safeParse(JSON.parse(partContent));
	if (!partResult.success) continue;
	const part = partResult.data as Record<string, unknown>;

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 712-715

Comment:
**Same double JSON.parse in JSON path**

Same bug as in the SQLite path at line 509–512. `partContent` is validated through `OpenCodePartSchema.safeParse` but then re-parsed with a raw cast. Use the validated result:

```suggestion
        const partResult = OpenCodePartSchema.safeParse(JSON.parse(partContent));
        if (!partResult.success) continue;
        const part = partResult.data as Record<string, unknown>;
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

trimMessages() not used — handoff may have zero user messages

This uses a raw .slice() instead of the required trimMessages() helper from parser-helpers.ts. If the last N messages are all assistant messages, the handoff document loses all user context. The trimMessages() helper guarantees at least one user message is included.

Suggested change

	const trimmed = allMessages.slice(-resolvedConfig.recentMessages);
	const trimmed = trimMessages(allMessages, resolvedConfig.recentMessages);

Also requires adding the import: import { extractRepoFromCwd, homeDir, trimMessages } from '../utils/parser-helpers.js';

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/parsers/opencode.ts
Line: 1123

Comment:
**`trimMessages()` not used — handoff may have zero user messages**

This uses a raw `.slice()` instead of the required `trimMessages()` helper from `parser-helpers.ts`. If the last N messages are all assistant messages, the handoff document loses all user context. The `trimMessages()` helper guarantees at least one user message is included.

```suggestion
  const trimmed = trimMessages(allMessages, resolvedConfig.recentMessages);
```

Also requires adding the import: `import { extractRepoFromCwd, homeDir, trimMessages } from '../utils/parser-helpers.js';`

How can I resolve this? If you propose a fix, please make it concise.