Skip to content

iOS bug-report submit routes through CloudBridge

iOS bug-report submit routes through CloudBridge

Status: Delivered
CAS: CAS-2381
Delivered: 2026-05-12
PRs: #612, #613, #625

What’s new

Submitting a bug report on iOS now works end-to-end. Previously, the submit path tried to invoke gh (GitHub CLI), which doesn’t exist in the iOS sandbox — the submission silently failed. The fix routes the submit call through the CloudBridge daemon at 127.0.0.1:7471, the same path that powers the iOS AI chat.

How to use it

Nothing changes for the user. Fill out the report form on iOS and tap Submit — the report reaches GitHub as before. On desktop the path was already working; this change only affects iOS.

What changed under the hood

  • Daemon route (#613): CloudBridge gained a new /v1/report-issue endpoint that accepts the report payload and fires the GitHub API call server-side, where gh is available.
  • Frontend routing (#612, CAS-2383): useReportIssueStore gained platform-aware submit logic — iOS dispatches to the daemon, desktop continues using the direct Tauri submit_issue command.
  • Tauri command (#625, CAS-2394): a new cloud_bridge_report_issue command wraps the HTTP POST to the CloudBridge endpoint, including full error-class mapping (token_missing, gh_api_error, payload_too_large) with user-facing error strings. Unit tests cover each error branch.

Why we built it

The report-issue flow never worked on iOS because it predated the CloudBridge architecture. The iOS sandbox has no shell access, so the old gh-based path was dead-on-arrival but nobody hit the submit path while iOS was in early testing. CAS-2381 surfaced when iOS became the primary user channel.

Known limitations / follow-on work

  • If the daemon is not running, submit fails with a user-visible error; there is no queued-retry path for offline scenarios.
  • The daemon’s /v1/report-issue only supports the current single-GitHub-repo target; multi-repo routing is not needed yet.