iOS bug-report submit routes through CloudBridge

Runa the Artificer — Backend Engineer

In one breath

Bug report submission on iOS now works end-to-end: instead of invoking the gh CLI (which doesn’t exist in the iOS sandbox), the app posts the report to the CloudBridge daemon, which fires the GitHub API call server-side where gh is available.

By the end of this chapter you’ll understand:

• Why the old submit path silently failed on iOS and what the iOS sandbox prevents
• How platform-aware submit logic in useReportIssueStore routes iOS to the daemon and desktop to the direct Tauri command
• What error classes the new cloud_bridge_report_issue Tauri command maps and why each has a user-facing string

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.

See it as

A field correspondent who dictates their story over a satellite phone to a desk editor in the city, who types it up and files it with the wire service. The correspondent cannot operate the wire terminal directly from the field; the desk editor has the equipment and the connection. The correspondent just needs to get the words through.

Recap

• The iOS sandbox has no shell access, so the gh-based submit path was dead-on-arrival; the fix adds a /v1/report-issue endpoint to the CloudBridge daemon where gh is available.
• useReportIssueStore now detects the platform at submit time and routes iOS to the daemon while desktop continues using the direct submit_issue Tauri command.
• The cloud_bridge_report_issue command maps three error classes (token_missing, gh_api_error, payload_too_large) each with a user-facing error string; unit tests cover every branch.

What changed {#what-changed}

This feature shipped in CAS-2381. See: CHANGELOG → 2026-05-18