Add Debug action and modal to automation detail page

[DevinVinson]

Summary

Add a Debug option to the 3-dot menu on the single automation detail page (/automations/:id), in the top-right corner. When clicked, it should open a modal that shows:

• Basic log output for the automation
• The raw automation data/config
• Any recent logged activity associated with the automation and/or its runs

This should make it much easier to understand what happened during recent runs without needing to jump between the automation detail page, conversations, and backend/service logs.

Problem

Today, the automation detail page shows run history, status, and links to conversations when a conversation_id exists. However, it does not provide a direct debugging surface for:

• recent stdout/stderr or log excerpts
• failure details beyond limited run status context
• raw automation configuration as stored by the backend
• recent service activity tied to the automation or its runs

This makes debugging harder than it needs to be, especially for:

• failed runs with no obvious UI explanation
• runs that never created a conversation
• timeout / callback / dispatch issues
• verifying what configuration or trigger data was actually used

Proposal

On the automation detail page, add a new Debug item to the existing kebab/3-dot menu in the header.

When selected, open a modal with sections such as:

1. Basic Log Output

Show a bounded, readable log view for recent execution data, such as:

• stdout/stderr tail for the most recent run
• latest run error_detail
• timeout / callback / dispatch-related errors
• status and timestamps

2. Automation Data

Show the raw automation data for the current automation, for example:

• automation id
• name
• trigger
• prompt
• tarball path / entrypoint
• timeout
• enabled state
• timestamps
• any other relevant stored fields

A copy-to-clipboard action would be helpful here.

3. Recent Logged Activity

Show recent activity related to the automation and/or its recent runs, for example:

• recent runs with timestamps and statuses
• sandbox id (if available)
• conversation id (if available)
• recent backend events tied to the run / automation
• dispatch / completion / watchdog-related activity

This can start as a lightweight debug view and evolve later if needed.

Why this is useful

This would provide a single place to answer common debugging questions like:

• Did the automation actually start?
• Which run failed?
• Was a sandbox created?
• Was a conversation created?
• What config did this automation use?
• Was this a dispatch problem, execution problem, or callback problem?
• Did the watchdog mark the run as failed after timeout?

Suggested scope for v1

A good initial version does not need to be a full live terminal or interactive debugger.

A useful v1 could be:

• Add Debug action to the automation detail page menu
• Add modal UI
• Display:
  • current automation JSON/data
  • recent runs
  • latest error_detail
  • any available recent log tail / activity summary
• Keep the output bounded and read-only

Backend considerations

There is currently useful run metadata available via the runs API, but there is not yet a dedicated persisted run-log store. A v1 implementation could likely build on existing data first, then expand later.

Potential sources:

• automation detail endpoint
• automation runs endpoint
• recent run metadata (error_detail, conversation_id, sandbox_id, etc.)
• recent service-side activity if exposed safely
• persisted stdout/stderr tail if added as part of this feature

If needed, this issue can include adding a small backend endpoint for debug payloads, e.g. something like:

• GET /api/automation/v1/{automation_id}/debug

or

• GET /api/automation/v1/runs/{run_id}/logs

depending on how we want to shape the data.

UX notes

• The Debug menu item should appear on the single automation detail page
• It should be visible from the top-right kebab menu near the existing actions
• Modal should support:
  • scrolling
  • monospace formatting for logs / JSON
  • copy buttons where useful
• If logs are unavailable, show a clear empty state instead of failing silently

Acceptance criteria

• A Debug action is available in the automation detail page 3-dot menu
• Clicking Debug opens a modal
• The modal shows the current automation's underlying data/config
• The modal shows recent run/debug information for the automation
• The modal shows basic log output or a clear "no logs available" state
• The modal is read-only and safe to expose to the automation owner
• Errors/loading states are handled cleanly
• Tests are added for the new UI behavior and any new API surface

Non-goals for v1

• Full interactive shell access
• Live terminal streaming
• Editing automation configuration from the debug modal
• Keeping sandboxes alive solely for this feature

Open questions

• Should the modal focus only on the latest run, or allow selecting among recent runs?
• Should we expose only bounded log tails, or full logs when available?
• Do we want a dedicated debug endpoint, or should the frontend compose this from existing APIs plus a small new logs endpoint?
• Should sandbox_id and conversation_id be shown directly in the modal?
• Do we want copy/download support for the debug payload?

---

This issue was created by an AI agent (OpenHands) on behalf of the user.

[linear]

APP-1545