feat(tools): save large task outputs to file to prevent truncation

[harshav167]

Summary

When background-task or call-omo-agent responses exceed 15,000 characters, the tool output can be truncated, causing the main agent to lose context and often re-read the entire codebase unnecessarily.

This PR saves large outputs to ~/.local/share/opencode/storage/task-outputs/ and returns:

• The file path to the full output
• A 2,000 character preview

Changes

• background-task/tools.ts: Added file-based output for formatTaskResult when output exceeds threshold
• call-omo-agent/tools.ts: Added file-based output for sync mode responses when they exceed threshold

Implementation Details

• Threshold: 15,000 characters
• Output location: ~/.local/share/opencode/storage/task-outputs/
• File naming: {tool}_{task-id}_{timestamp}.md
• Uses existing getOpenCodeStorageDir() helper for consistent data path handling

Testing

• Type check passes
• Manual testing confirmed outputs are saved correctly

[greptile-apps]

Greptile Summary

Added file-based storage for large outputs (>15k chars) in background_task and call_omo_agent tools to prevent truncation and context loss when agents return extensive results.

Key Changes

• Implemented 15,000 character threshold to detect large outputs
• Large outputs saved to ~/.local/share/opencode/storage/task-outputs/ with format {tool}_{id}_{timestamp}.md
• Returns file path + 2,000 character preview instead of full output
• Uses existing getOpenCodeStorageDir() helper for consistent data path handling

Issues Found

• Critical: File write operations lack error handling for disk full, permission denied, or I/O errors - if writing fails, the entire tool will crash
• Code Quality: Helper functions (getTaskOutputsDir, saveOutputToFile, truncateText) are duplicated across both files instead of being extracted to a shared utility module

Confidence Score: 3/5

• This PR solves a real problem but has critical error handling gaps that could cause tool crashes
• The implementation addresses truncation issues effectively, but lacks error handling around file I/O operations. If disk is full or permissions are denied, writeFileSync will throw uncaught errors causing the entire tool execution to fail. Additionally, code duplication creates maintenance burden
• Both files need error handling added to saveOutputToFile() functions before merge. Consider extracting shared utilities to reduce duplication

Important Files Changed

Filename	Overview
src/tools/background-task/tools.ts	Adds file-based storage for large task outputs (>15k chars) with 2k preview; duplicates helper functions that could be shared
src/tools/call-omo-agent/tools.ts	Adds file-based storage for large agent responses (>15k chars) with 2k preview; duplicates helper functions from background-task

Sequence Diagram

sequenceDiagram
    participant Agent as Main Agent
    participant Tool as background_task/call_omo_agent
    participant Check as Output Size Check
    participant Storage as File Storage
    participant Return as Tool Return

    Agent->>Tool: Execute tool with prompt
    Tool->>Tool: Process task/agent execution
    Tool->>Check: Check output.length > 15,000?
    
    alt Output exceeds 15k chars
        Check->>Storage: getTaskOutputsDir()
        Storage->>Storage: Create ~/.local/share/opencode/storage/task-outputs/
        Check->>Storage: saveOutputToFile(id, content)
        Storage->>Storage: Write {tool}_{id}_{timestamp}.md
        Storage-->>Check: Return file path
        Check->>Check: truncateText(content, 2000)
        Check->>Return: Format with file path + preview
        Return-->>Agent: Large Output message with file ref
    else Output within limit
        Check->>Return: Return full output directly
        Return-->>Agent: Complete output inline
    end

Loading

[greptile-apps]

Additional Comments (3)

1. src/tools/background-task/tools.ts, line 96-116 (link)

   style: these helper functions (getTaskOutputsDir, saveOutputToFile, truncateText) are duplicated in call-omo-agent/tools.ts. extract to shared utility file to maintain DRY principle

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

2. src/tools/background-task/tools.ts, line 104-111 (link)

   logic: wrap file write in try-catch to handle potential errors (disk full, permission denied, etc.)

3. src/tools/call-omo-agent/tools.ts, line 20-27 (link)

   logic: wrap file write in try-catch to handle potential errors (disk full, permission denied, etc.)

_{2 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[code-yeongyu]

This is cool!

[code-yeongyu]

i am thinking of where to save that file between tmp/ or persistence file path

[code-yeongyu]

I think i am talking with another agent lool

[harshav167]

i am thinking of where to save that file between tmp/ or persistence file path

I'd recommend tmp/ for this use case. Here's why:

Context: Replicating Claude Code's Behavior

Claude Code handles large outputs (100k+ chars) by saving to disk to prevent context bloat. Their pattern:

• Save to project-scoped path: ~/.claude/projects/<project>/tool-results/<tool>-<timestamp>.txt
• Return error message with file path + instructions for reading chunks

Why tmp/ makes sense for us:

1. Ephemeral by nature - These outputs are only needed during the current session. Once the agent reads the file and extracts what it needs, the full output has no value.

2. Auto-cleanup - OS cleans tmp on reboot. No manual cleanup needed, no disk space accumulation over time.

3. No persistence guarantees needed - Unlike session data or configs, losing these files between sessions is fine (even expected).

4. Claude's approach is project-scoped - They use ~/.claude/projects/<project>/... which ties outputs to specific projects. We don't have that project context in OMO, so tmp/ is simpler.

Proposed path structure:

{os.tmpdir()}/opencode-task-outputs/{tool}_{id}_{timestamp}.md

Additional fixes in this update:

• Extract duplicated code to src/shared/task-output.ts
• Add error handling for file I/O (graceful fallback to inline if write fails)

Let me know if you'd prefer persistent storage instead!

[harshav167]

Ha! Yes, same agent here — just continuing across sessions. 🙂

Updates are done and pushed:

• Extracted shared utilities to src/shared/task-output.ts
• Added error handling with fallback to inline output if file write fails
• Switched to os.tmpdir() for ephemeral storage (auto-cleans on reboot)
• Typecheck passes ✓

Ready for your review when you have a chance!

[harshav167]

I think i am talking with another agent lool

haha its actually me here im using omo to code this feature as well. im basically tryna replicate the claude code feature with this plugin which was recently added

[code-yeongyu]

I think i am talking with another agent lool

haha its actually me here im using omo to code this feature as well. im basically tryna replicate the claude code feature with this plugin which was recently added

great- can you give me some time to review? i think i have to organize of my thoughts!

[harshav167]

I think i am talking with another agent lool

haha its actually me here im using omo to code this feature as well. im basically tryna replicate the claude code feature with this plugin which was recently added

great- can you give me some time to review? i think i have to organize of my thoughts!

yeah no worries take your time im resolving conflicts now, basically added this feature on the fly while i was coding in another session and the session crashed a few times cause of context limits during agent and tool calls