Store recent agent traces for local access

[tom-rigelblu]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Feature Suggestion: store recent agent traces for local access

Open Questions: if this is done, not sure what local access for warp / oz cloud might mean

Is your feature request related to a problem? Please describe.

Use Case: I'm trying the new custom endpoints with the gemma models on google api. I can't see much what's causing it to not want execute it's plan

I'm trying with droid and it has issues too, but I can investigate why by looking at the traces with another tool

@oz-agent when you review this issue, please extract the relevant information from the images

Warp conversation

Output of trace visualization tool

Additional context

No response

Operating system (OS)

macOS

How important is this feature to you?

3

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

None

[oz-for-oss]

@tom-rigelblu

Here's what I found while triaging this issue:

This overlaps with #10112’s machine-readable export request, but this report adds a custom endpoint debugging use case and a concrete comparison to an external trace viewer.

I have a few follow-up questions before I can narrow this down:

1. Which trace contents would make your custom endpoint debugging workflow useful: the conversation/tool-call timeline only, or raw provider request/response details as well?
2. Would a manual structured export for the current conversation solve your need, or do you need Warp to automatically keep recent trace files locally for every agent run?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that feature request for user-accessible structured local traces of recent agent runs, especially to debug custom endpoint/model behavior..

Triage summary

This is an enhancement request for local access to recent structured agent traces, motivated by debugging custom endpoint/Gemma behavior where the agent appears not to execute its plan. The attached Warp screenshot shows the conversation UI exposing high-level agent thinking and actions, while the trace-viewer screenshot shows more structured sections for prompts, agent responses, thinking, and tool calls that make debugging easier.

Code/context notes

• app/src/search/slash_command_menu/static_commands/commands.rs defines /export-to-clipboard and /export-to-file as Markdown-only conversation export commands.
• app/src/persistence/agent.rs stores recent agent conversations/tasks in local SQLite for app restore and prunes after a bounded history, but this is internal persistence rather than a user-owned trace artifact.
• app/src/ai/agent/api/impl.rs sends MAA requests with model/custom-provider settings and streams responses back to the client; I did not find a user-facing path that writes raw structured request/response/tool-call trace files for recent runs.
• app/src/ai/agent/api/convert_conversation.rs documents that restored conversation conversion can be lossy, which is another reason a dedicated trace/export format may need its own contract.

Duplicate check

I enumerated 3,496 open issues via the GitHub API. #10112 is closely related because it requests machine-readable local export for agent conversations, including structured trace files, but I found fewer than two likely duplicate issues and this report adds a specific custom-endpoint debugging use case, so I am not marking this as a duplicate.

Open questions

The remaining ambiguity is product scope: what counts as a useful trace and how it should work for local vs cloud/Oz runs.

Question reasoning

1. Which trace contents would make your custom endpoint debugging workflow useful: the conversation/tool-call timeline only, or raw provider request/response details as well? — The report asks for agent traces, but the implementation scope differs significantly between structured conversation export and raw model/provider payload tracing.
2. Would a manual structured export for the current conversation solve your need, or do you need Warp to automatically keep recent trace files locally for every agent run? — The report says to store recent traces for local access, but it is unclear whether automatic rolling persistence is required or whether extending the existing export flow is sufficient.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[tom-rigelblu]

1. I'm not experienced enough on this part, so here's an agent's desponse

Both, but they're not equal weight for this use case. The conversation/tool-call timeline is how I navigate and find the suspect step. The raw provider request/response is how I actually debug it — custom-endpoint failures are wire-level (tool schemas, finish_reason/stop_reason, streaming SSE framing, headers, base_url rewrites, raw error bodies), and the timeline normalizes exactly that layer away.
Concretely, what makes it useful: per step, let me drill from the timeline into (a) the post-serialization request body + headers + actual URL, and (b) the raw response body including error and streaming chunks. Storing the pre-serialization request too would be a bonus — the SDK-built vs. on-the-wire diff is often the bug itself. Since it's local, I'd rather have full fidelity with optional secret-masking than a redacted-by-default view.
If you have to sequence it: raw request/response first, timeline as the index over it. The reverse leaves the feature unable to do the one thing I'm asking for.

• Claude

2. I would call "manual structured export" a sub-feature of this feature request. It'd make for a better experience if all conversations were locally accessible so other tools could have access without user action

[oz-for-oss]

@tom-rigelblu

This issue appears to overlap with existing issues:

• Agent conversations lack machine-readable export #10112 — Agent conversations lack machine-readable export
• Feature request: Persist agent thinking/reasoning output for review after response completes #9702 — Feature request: Persist agent thinking/reasoning output for review after response completes

If this report is meaningfully different, please comment with the additional context or distinguishing behavior so a maintainer can review it. Otherwise, a maintainer may close it as a duplicate after review.

Maintainer details

I concluded that feature request for locally accessible recent agent traces/structured conversation data, likely duplicating existing requests for machine-readable agent export and persisted reasoning output..

Duplicate reasoning

• Agent conversations lack machine-readable export #10112: Both requests ask for locally accessible, machine-readable/structured agent conversation traces so external tools can inspect turns, tool calls, metadata, and events without relying only on internal or cloud storage.
• Feature request: Persist agent thinking/reasoning output for review after response completes #9702: Both requests focus on preserving agent reasoning/trace details after a run so users can debug unexpected behavior, with Feature request: Persist agent thinking/reasoning output for review after response completes #9702 explicitly requesting export/share support for that persisted reasoning.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[tom-rigelblu]

@oz-agent I updated my last comment, please re-read and evaluate

[oz-for-oss]

@tom-rigelblu

Here's what I found while triaging this issue:

• Thanks for the update. This overlaps with Agent conversations lack machine-readable export #10112’s structured local export request, but your latest comment clarifies a more specific need: raw custom-endpoint request/response details, with the timeline mainly serving as an index.
• I’m routing this as an agent enhancement rather than a bug because the report describes a missing debugging/export capability, not a single failing Warp behavior with a narrow repro/fix path.

Maintainer details

I concluded that feature request to make recent Warp/Oz agent traces locally accessible, with particular emphasis on raw custom-endpoint provider request/response data for debugging..

Triage summary

This is an area:agent enhancement request for local access to recent Warp/Oz agent traces. The updated reporter comment makes the requested shape more specific than a generic transcript export: for custom-endpoint debugging, the most valuable artifact is the raw provider request/response data, with the timeline acting as an index into it.

Evidence from the report

• The feature request asks to store recent agent traces for local access while testing custom endpoints with Gemma models on Google API.
• The Warp screenshot shows an agent conversation where the agent repeatedly reasons about invoking /vcs-change commit wo, plans to inspect jj state, and does not clearly execute the intended skill flow.
• The trace-visualization screenshot shows the kind of data the reporter can inspect in another tool: prompt/agent-response/thinking/tool-call categories, a raw skill-use thought, and a command event.
• The follow-up comment clarifies priority: raw request/response first, timeline second as an index. The reporter specifically calls out post-serialization request body, headers, actual URL, raw response body, errors, and streaming chunks; pre-serialization request data would be a bonus.

Code context

• app/src/persistence/agent.rs persists up to 100 local agent conversations as conversation metadata plus protobuf tasks for restore/navigation.
• app/src/ai/agent/conversation.rs writes persisted conversation state from all_tasks().filter_map(|task| task.source_for_persistence()) plus metadata such as server conversation token, artifacts, usage, parent/run IDs, and autoexecute state. This supports restoring the normalized conversation, not storing raw provider wire payloads.
• app/src/ai/blocklist/history_model.rs and app/src/ai/agent/api/convert_conversation.rs restore conversations into UI exchanges/messages; restored output uses normalized messages and leaves api_metadata_bytes unset.
• app/src/ai/agent/api.rs builds RequestParams with BYOK API keys and custom_model_providers for custom endpoints; app/src/ai/blocklist/controller/response_stream.rs keeps these params in an in-flight response stream for request execution/retry, not as a durable local debugging artifact.
• app/src/settings_view/custom_inference_modal.rs, app/src/settings_view/ai_page.rs, and app/src/ai/llms.rs cover custom endpoint configuration/model selection and confirm the feature surface is custom inference endpoints for Warp Agent.

Dedupe notes

The closest open related issue is #10112 (Agent conversations lack machine-readable export), which asks for a structured local export or automatic local structured trace files. #11633 overlaps that direction but adds a more specific custom-endpoint debugging requirement: full-fidelity raw provider request/response details. I found only one strong duplicate candidate in the required all-open-issue scan, so duplicate_of is left empty per the two-candidate dedupe threshold.

Suggested routing

Route as an agent enhancement. This likely needs product/security design before implementation because storing raw headers, request bodies, responses, and SSE chunks locally intersects with secret masking, retention, disk location, cloud-vs-local agent boundaries, and whether the artifact is automatic, manual export, or both.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz