[muvaf]

Summary

Give each Limrun recording its own ID so stopping or cleaning it cannot stop another recorder on the instance. iOS and Android use @limrun/api 0.68.1 recording sessions. Download retries reuse the completed stop result.

Seven files; independent follow-up to #4174. Commands remain agent-device record start capture.mp4 and agent-device record stop.

Related work

This series replaces Limrun iOS AX with native XCTest through shared local paths. Prerequisites #4174, #4194, and #4195 are merged. Shared Apple tools #4213 and this PR remain upstream. Fork drafts track native XCTest integration #1, then sync install/reinstall #2. They need rebasing onto merged prerequisites and fresh live validation; the native integration also needs splitting before upstream submission.

Validation

Base a2c169fa502a53f1f2a1da25b1cd16b9c731af39; tested head ad71d0391615ee336f0157941f473e204cfd0be8.

pnpm check:affected --run --base <base> --head <head> passed with exactCommit: true: 17,139 unit and 245 provider tests; one skipped. Live Limrun Android 15 and iOS 26.4 preserved an external recording through stop, forced download failure, retry and close. Retry reused one URL and sent no second stop. Eight MP4s decoded; instances terminated. Commands, videos and receipts.

GitHub owns device smoke, coverage and provider integration checks not included locally.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[vercel]

@muvaf is attempting to deploy a commit to the Callstack Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

No issues found across 7 files

_{View guided diff | Re-trigger cubic}

[thymikee]

The recording isolation change at 159c1b0 needs live validation before merge. The Android route calls new remote recording-session endpoints, and mocked adapters cannot establish remote isolation or SDK/server compatibility. Could you provide head-attributed commands and output for daemon record start/stop and close cleanup on a live Limrun Android instance with an independent recording on the same instance? Please show the external recording remains active after each operation, valid downloaded MP4s, and session and instance cleanup. Please also exercise a failed download followed by record stop retry and show that it reuses the first recording URL without another remote stop while the other recording remains active. Include the SHA, instance and runtime, and make the existing iOS commands, output and receipts accessible.

The captured Vercel failure concerns contributor deployment authorization and appears unrelated to the Limrun changes; please resolve that authorization separately. No conflicts are known. Complete the live Android evidence and accessible iOS and validation receipts before merge.

[muvaf]

The requested live evidence is published for current head ad71d0391615ee336f0157941f473e204cfd0be8:

• Report and reproducible harness, with the SHA, instance IDs, runtimes, MP4 decode results, and cleanup.
• Android commands/output and summary.
• iOS commands/output and summary.
• Exact-commit validation receipt.

Both platforms preserve an independent recording across normal stop, an injected download failure, retry, and close cleanup. The retry reuses the first URL with one remote stop. All eight MP4s decoded, and both owned instances were terminated. The PR description links this evidence as well.

The Vercel check still requires authorization by a Callstack team member; I cannot grant that team permission from the fork.

[thymikee]

Thanks, the evidence at ad71d03 covers what I asked for. On both Android and iOS Limrun instances, the independent recording stayed active through daemon record start, record stop and close. You show that with the incompatible-quality probe, which the server rejects only while another recording is running. The injected download failure followed by a retry reused the first URL with one remote stop, all eight MP4s decoded, and both instances were cleaned up. The exact-commit receipt is attached too.

The code looked right in the earlier review, and no review threads are open. The only failing check is the Vercel deployment authorization, which is not a code problem. No conflicts are known.