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-issueendpoint that accepts the report payload and fires the GitHub API call server-side, whereghis available. - Frontend routing (
#612, CAS-2383):useReportIssueStoregained platform-aware submit logic — iOS dispatches to the daemon, desktop continues using the direct Taurisubmit_issuecommand. - Tauri command (
#625, CAS-2394): a newcloud_bridge_report_issuecommand 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-issueonly supports the current single-GitHub-repo target; multi-repo routing is not needed yet.