Diagnostics — one-click GitHub upload

[samanthamsong]

Epic: «Ship & update the node with confidence» (#838)
Backlog Doc ID: #34 · Priority: P2 · Area: release

Description
One-click upload of diagnostics to GitHub.

Definition of done
A user can attach scrubbed diagnostics to a GitHub issue in one click.

Part of the «Ship & update the node with confidence» tracking issue (#838).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 26, 2026, 2:47 PM ET / 18:47 UTC.

Summary
Keep open: current main and the latest release have diagnostics bundle preview/copy/save surfaces, but they do not provide the requested one-click GitHub issue upload or attachment flow.

Reproducibility: not applicable. this is a feature request, not a report of broken existing behavior. Source inspection verifies that current main supports preview/copy/save diagnostics bundles but not one-click GitHub upload.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Maintainers should decide the GitHub upload/auth and scrub-before-upload policy before an implementation PR is queued.

Review details

Best possible solution:

Add a maintainer-approved diagnostics sharing flow that reuses the existing bundle UI, routes all exported content through the agreed scrub boundary, and either opens a prefilled GitHub issue with an attachable file or performs an authenticated upload with explicit user confirmation.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a feature request, not a report of broken existing behavior. Source inspection verifies that current main supports preview/copy/save diagnostics bundles but not one-click GitHub upload.

Is this the best way to solve the issue?

Unclear: one-click GitHub upload is the requested outcome, but the safest implementation depends on maintainer decisions about GitHub auth, issue selection, user confirmation, and the PII-scrubbing boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The design needs maintainer product/security direction for how the app reaches GitHub without asking users for unnecessary repository credentials or silently posting diagnostics.
• The upload flow should remain blocked on the scrub-before-upload boundary tracked by Diagnostics — PII scrubbing #857 so local paths, endpoints, identifiers, and log details are not exposed accidentally.

Codex review notes: model internal, reasoning high; reviewed against 1c377cb64b65.

Label changes

Label changes:

• add P2: The issue is a normal-priority release-support improvement with bounded blast radius, not an emergency regression.
• add impact:security: The requested feature uploads diagnostic data off-device and depends on safe scrubbing of potentially sensitive content.
• add impact:other: The feature materially affects supportability and release diagnostics, which does not fit the narrower runtime impact labels.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The issue is a normal-priority release-support improvement with bounded blast radius, not an emergency regression.
• impact:security: The requested feature uploads diagnostic data off-device and depends on safe scrubbing of potentially sensitive content.
• impact:other: The feature materially affects supportability and release diagnostics, which does not fit the narrower runtime impact labels.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore

What I checked:

• Repository policy read: AGENTS.md was found at the target repository root and read fully before review; its validation rules did not require test execution because this was a read-only review with no code changes. (AGENTS.md:1, 1c377cb64b65)
• No VISION.md present: No VISION.md was found in or near the target checkout, so issue fit is unclear rather than explicitly accepted or rejected by a vision document. (1c377cb64b65)
• Issue and parent context: The issue asks for one-click upload of scrubbed diagnostics to a GitHub issue and is listed as a child of the open release-confidence tracking issue.
• Existing diagnostics UI creates a local bundle: The Diagnostics page has a Create diagnostics bundle card that previews connection, gateway, port, capability, log-tail, and device context before sharing, but the UI action is not an upload action. (src/OpenClaw.Tray.WinUI/Pages/DebugPage.xaml:119, 1c377cb64b65)
• Bundle handler opens preview with a local text filename: OnCreateDiagnosticsBundle builds CommandCenterTextHelper.BuildDebugBundle, suggests an openclaw-diagnostics timestamped .txt filename, and shows DiagnosticsBundleDialog; it does not call any GitHub or upload service. (src/OpenClaw.Tray.WinUI/Pages/DebugPage.xaml.cs:457, 1c377cb64b65)
• Dialog supports copy and save only: DiagnosticsBundleDialog exposes Copy to clipboard, Save to file, and Close buttons; the code copies text or writes a local text file via FileSavePicker. (src/OpenClaw.Tray.WinUI/Windows/DiagnosticsBundleDialog.xaml:8, 1c377cb64b65)

Likely related people:

• bkudiess: The task-oriented Diagnostics page and preview-then-share diagnostics bundle were introduced in the diagnostics page rebuild commit attributed to the bkudiess tray UX stack. (role: diagnostics UX introducer; confidence: high; commits: 84ceee19c03d; files: src/OpenClaw.Tray.WinUI/Pages/DebugPage.xaml, src/OpenClaw.Tray.WinUI/Pages/DebugPage.xaml.cs, src/OpenClaw.Tray.WinUI/Windows/DiagnosticsBundleDialog.xaml.cs)
• Ranjesh: Recent history shows Ranjesh applied the tray UX stack and extracted DiagnosticsClipboardService, touching the current diagnostics page and copy/deep-link surfaces. (role: recent diagnostics UX integrator; confidence: medium; commits: 429be9ba9368, fb9f30de50e4; files: src/OpenClaw.Tray.WinUI/Pages/DebugPage.xaml, src/OpenClaw.Tray.WinUI/Pages/DebugPage.xaml.cs, src/OpenClaw.Tray.WinUI/Services/DiagnosticsClipboardService.cs)
• Scott Hanselman: History ties the earlier debug bundle entrypoint to this author, adjacent to the current diagnostics sharing surface. (role: diagnostics entrypoint contributor; confidence: medium; commits: 62d7e0c28b44; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/Services/DeepLinkHandler.cs, README.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.