Summary

When a workflow triggers a browser download, agents need a reliable way to capture the downloaded artifact for subsequent tool use.

Today, downloads can complete successfully in the browser while remaining inaccessible to downstream agent steps.

Problem

This gap blocks common automation flows that depend on exported files (JSON/CSV/PDF/etc.) and forces brittle workarounds.

Proposed Solutions

Option A: Download event capture (preferred)

Return structured metadata on completed download in tool response:

{
  "ok": true,
  "download": {
    "filename": "example.json",
    "path": "/tmp/openclaw/downloads/example.json",
    "size": 2345,
    "mimeType": "application/json"
  }
}

Option B: Configurable download directory

Expose a deterministic agent-readable path:

browser:
  downloadPath: /tmp/openclaw/downloads

Option C: Dedicated browser action=download

Allow explicit wait/capture for next download event:

{ "action": "download", "profile": "openclaw", "timeoutMs": 10000 }

Related Issues

• [Bug]: macOS Sequoia: OpenClaw isolated Chrome profile cannot download CSV (chrome://downloads entry is unclickable + wrong filename) #18598
• bug: downloads fail path validation when explicit output path is outside DEFAULT_DOWNLOAD_DIR #33067
• [Bug]: browser upload rejects valid files inside /tmp/openclaw/uploads #23107

Environment

• OpenClaw 2026.3.2 (85377a2)
• Browser profile: openclaw (isolated Chromium)

Impact

This affects any UI automation that requires downloaded artifacts as inputs to subsequent steps. First-class download capture would remove a major reliability gap in end-to-end browser workflows.