A persistent phone does not need to keep running between tasks. Mobilebox separates the sandbox’s stored state from its running session: park shuts the phone down while retaining apps, data, and logins.
That distinction helps an agent that returns to the same app account. It also changes what the agent should assume after resume.
What park keeps
Installed apps and their stored data remain. App logins remain to the extent that the app itself stores and accepts the session. Server-side expiration, revocation, and security checks still belong to the app; parking cannot guarantee that a third-party login will remain valid forever.
Running processes do not remain live. Apps start fresh after resume, like after a reboot. Do not expect an unsaved form, an in-memory navigation state, or an active socket to survive.
The lifecycle calls
# Shut down; retain app data.
curl --fail-with-body -X POST "$MSB/v1/phones/$ID/park" \
-H "Authorization: Bearer $MOBILESANDBOX_API_KEY"
# Resume and wait for readiness within this request's timeout.
curl --fail-with-body -X POST "$MSB/v1/phones/$ID/start?wait=ready" \
-H "Authorization: Bearer $MOBILESANDBOX_API_KEY"A wait call can return before boot is ready. Inspect status and poll the same phone; do not duplicate it. The quickstart includes a bounded polling example.
When delete is better
Delete removes the phone and its data. Use it for disposable tests, incompatible state, or a task whose data should not be retained. Park is appropriate when the next task should reuse the installed app and its stored session.
The default capacity limits count parked phones toward the total phone count. A parked fleet therefore still needs intentional ownership and cleanup, even though parked time is free.
Verify persistence explicitly
Write a harmless value in your test app, confirm it is saved, park, resume, reopen the app, and read the value. That is stronger evidence than seeing the app icon remain installed.
Our recorded run did this on October 29, 2026, on an Android 14 arm64 virtual sandbox. It saved a release checklist in Fossify Notes, then terminated and reopened the app. It parked and resumed the phone, reopened the app, and found the checklist still there. This is a recording, not a live phone. It shows one app’s saved data. It does not cover unsaved state and is not a promise for every app. Details: how it was captured and captured operations and frame hashes.
If the app returns to sign-in, distinguish a lost local state from an expired remote session. Observe before retrying credentials or reinstalling. The phone lifecycle and the application’s session lifecycle are related, but they are not the same contract.