feat(limrun): read and write the iOS clipboard on Limrun instances

[jbroma]

Summary

clipboard read and clipboard write now work on Limrun iOS. They were refused with "Limrun iOS direct sessions do not expose clipboard access yet". The provider now runs simctl pbpaste and simctl pbcopy (text on stdin) through Limrun's simctl, and both commands are on Limrun's allowed list.

agent-device clipboard write 'Rork clipboard ✓ ąę'
agent-device clipboard read

• simctl stdin first shipped in @limrun/api 0.56, so this bumps it from ^0.49.3 to ^0.59.0. 0.59 types status.token as optional, so app-log reattach now treats a missing token like a missing apiUrl (missing), with a test.
• limrunClipboardOperationFacts loses its unused device parameter: both legs admit read and write.
• Limrun docs list clipboard support.

11 files.

Validation

Rebased onto main after #3258 at 3805fb795: pnpm check:affected --run passes, and a live Limrun iOS run on that head pastes after rebase ✓ into the test app, reads back copied by app ✓, and presses home.

At 5b1fc40b4:

• pnpm check:affected --run passes; eager-closure budgets pass.

• Live on a Limrun iOS instance attached with only LIM_IOS_INSTANCE_URL/TOKEN, with a test app that has a SwiftUI PasteButton and a button that sets UIPasteboard.general.string:

  • clipboard write 'Rork clipboard ✓ ąę', tap Paste: the app shows pasted: Rork clipboard ✓ ąę.
  • Tap "Copy from app", clipboard read: copied by app ✓.

  So the app sees what pbcopy writes, unlike the local Xcode 27 case that moved local writes to the runner.

• The SDK bump, checked with tester-army/e2e on Limrun: the iOS suite (leases, settings, launch arguments, AI steps) passes. The Android suite gives the same 18 passed / 5 failed as with 0.49.3; the 5 failures fail the same way on both versions.

[cubic-dev-ai]

2 issues found across 11 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/provider-limrun/src/ios.ts">

<violation number="1" location="packages/provider-limrun/src/ios.ts:361">
P2: This removes a newline that belongs to clipboard text, so content written with a trailing `\n` does not round-trip. Preserve the normalized stdout instead of removing its final newline.</violation>
</file>

<file name="packages/provider-limrun/src/interaction-operations.ts">

<violation number="1" location="packages/provider-limrun/src/interaction-operations.ts:263">
P3: `limrunClipboardOperationFacts` now carries two stacked JSDoc blocks: the rewritten clipboard block (added here) plus a stale `keyboard` block that was left stranded directly above it. The keyboard text documents `limrunKeyboardOperationFacts`, which sits at the end of the file with no doc comment at all, so IDE hover/intent for the clipboard function reads the wrong operation and the keyboard function reads nothing. Move the `keyboard` block to `limrunKeyboardOperationFacts` or delete it, leaving only the clipboard block above this function.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Turn on auto-fix | Re-trigger cubic</sub>

[thymikee]

This PR is ready at 185981c. The clipboard read and write routes on Limrun iOS look correct, and all 17 checks pass, including typecheck on the SDK 0.59 types. There are no conflicts, and nothing else needs to happen before merge.

Not blocking: readClipboard in packages/provider-limrun/src/ios.ts repeats the pbpaste newline normalization from packages/platform-apple/src/core/app-device-io.ts, so a shared host-kit or contracts helper makes sense if a third site appears. The tests in ios-interactor-clipboard.test.ts only check the arguments sent to a hand-built simctl mock, so UTF-8 integrity depends on the SDK and no test covers it. The pasteboard call also has no timeout, like the existing launch call. You can take or leave these.

On evidence, I did not reproduce the live Limrun iOS run. It is author-reported at 5b1fc40, and 185981c only moves a comment. The Limrun server's allowed-command list for pbpaste and pbcopy is not visible from the SDK types, so only that live run covers it. I also did not diff SDK 0.49.3 to 0.59.0 beyond the status typing change and the simctl stdin path.

The cubic-dev-ai thread on the single trailing newline strip does not apply: it matches the local read route, so it is existing parity and you can resolve it (#3259 (comment)). The cubic-dev-ai thread on the keyboard doc block does not apply: at head that block sits above limrunKeyboardOperationFacts, so you can resolve it (#3259 (comment)).

[thymikee]

pls rebase