Mobile Agent Data Deletion

Effective date: 2026-07-28

Mobile Agent uses QR pairing without requiring an account. An account-enabled

distribution can optionally use email OTP to sync already linked Hosts across

devices. The app otherwise stores only the data needed to maintain pairings,

route encrypted messages, and keep limited local state.

Delete Data From Your Device

You can remove local pairing data from the app:

  1. Open Mobile Agent.
  2. Open Hosts.
  3. Select the paired machine.
  4. Tap "接続を解除." The app first asks the Relay to revoke any candidate,

quarantined, or previous credential for that machine and then the active

device, including its Push registration. Once every required revocation is

confirmed, the app removes the paired machine, local keys, and connection

metadata.

If Relay revocation cannot be confirmed, the app shows removal as pending and

keeps the local credentials needed to retry. It does not report the Host as

deleted or remove those credentials first. Retry after reconnecting, or use the

relay-side deletion request below if the Relay remains unavailable.

Non-secret instruction drafts are stored only in encrypted form. A draft is

deleted after its successful send or when you explicitly discard it. Removing

the final paired Bridge deletes every remaining draft and the shared

draft-encryption key. If another Bridge remains paired, the shared draft store

and key are retained for the pairings that remain. Answers to agent questions

marked secret are never saved as drafts or durable Inbox content.

Draft scope is encoded as a structured tuple of Host, Project, Session, task,

interaction, and question identifiers as applicable, so delimiter characters

inside an identifier cannot select another target's draft or mutation ID. On

the first draft operation after upgrading from the older delimiter-based

format, the app deletes every legacy-v1 encrypted draft before it reads or

writes v2; it does not guess a target or migrate ambiguous drafts. Unrelated

app preferences are retained.

Voice Fast Lane consent is scoped to a hashed Host, random pairing credential,

and Project. Confirmed Host removal deletes that credential's opt-in and

Project-scope records. A content-free tombstone containing only hashes of the

Host and revoked random pairing credential remains until you clear the app's

data; this prevents delayed local work from restoring consent for a revoked

credential. It contains no Project name or ID, Provider, Session, transcript,

instruction, or key material.

Eligible non-secret actions may also have encrypted, device-only Mobile Unblock

correlation records. Removing a paired Host clears records for that Host.

Pending records expire after 10 minutes and deduplication records expire after

30 days even if you keep the pairing. These identifiers are never sent to

Firebase Analytics.

Approvals and non-secret choice-only input may have a separate encrypted,

device-only safe-action retry entry. Approval entries contain a content-free

SHA-256 route/decision fingerprint. For choice-only input, normalized answer

values are processed only in memory with a random per-install HMAC key; only

the resulting opaque binding is incorporated into the SHA-256 retry

fingerprint. The store contains the fingerprint, a random retry-stable mutation

ID, and an update time—not raw answers, question text, commands, or approval

context. Explicit success or known failure deletes the entry.

Delivery-unknown entries expire within 30 days. A delivery-unknown choice entry

created by a version that predates answer binding is not rebound or retried; it

fails closed until it expires. Confirmed Host removal deletes that Host's

entries; removing the final Host clears the store and its HMAC key.

After you confirm a valid QR or pasted pairing payload, an encrypted pairing

recovery journal may keep the attempt method, start time, machine/Relay

routing, recovery stage, and—only after enrollment is acknowledged—the new

device credential, any rejected credential quarantined for revocation, and any

previous re-pair credential. It never retains the one-time QR secret. Attempts

use a 10-minute readiness deadline. Credentials needed to undo a failed pairing or retire an old device remain until Relay

revocation is confirmed; a content-free completion record may then remain for

up to 30 days to prevent duplicate outcomes. Confirmed explicit Host removal

clears that Host's journal records after every relevant credential is revoked.

Unreadable, corrupt, or unsupported journal state is preserved and pairing

changes are disabled rather than silently deleting a possibly live credential.

For provider-breadth measurement, encrypted secure storage keeps the first

successful-pairing timestamp, the first eligible Activation timestamp, and raw

provider IDs used to calculate a 1, 2, or 3_plus bucket. The raw values

never leave the device. Closed-test state expires no later than 35 days after

pairing or Activation; ISO-week state in other distributions expires no later

than seven days after the week. Removing one of several Hosts retains this

app-wide aggregate for the remaining Hosts. Removing the final Host deletes

the timestamps and provider-ID set immediately.

If you enabled Push, turning it off removes the Relay registration and local

Firebase token. Disconnecting a Host also requests removal of that Host's Push

registration. Cleanup remains pending if Relay deletion cannot be confirmed.

The paired Bridge may keep a content-free secret-interaction marker containing

only a Project ID, conversation/cascade ID, and taint time. It contains no

question, answer, instruction, value-derived hash, or Provider output.

Removing a Project from this app only unregisters the root; it does not delete

the selected provider's native conversation history. The marker therefore

survives unregistering and re-registering the same root so an old conversation

cannot re-enter durable Attention or result review without its privacy taint.

Remove it only after authoritatively deleting the corresponding Provider

conversation, or as part of an explicit full Bridge-local data deletion.

Task and Schedule state may also contain version-2 durable confirmation

envelopes. Each contains a random salt, machine-keyed authenticator,

content-free risk fingerprint, policy version, and approval time, but no

additional instruction copy, unkeyed instruction hash, machine secret, or

stable target token. Full Bridge-local data deletion removes these envelopes

with their Task and Schedule state.

The Bridge's durable Mutation, Task, Schedule, and Workspace ledgers use a

private sibling key for machine-keyed authentication. With the default paths,

the matched pairs are mutation-state.json plus mutation-state.json.key,

task-state.json plus task-state.json.key, schedule-state.json plus

schedule-state.json.key, and workspace-state.json plus

workspace-state.json.key; a custom state path uses <statePath>.key. The key

contains random key material, not an instruction, but it determines whether

the Bridge can trust replay results in its matching ledger and must be treated

as sensitive. Both the state file and sibling key are mode 0600, under a

private Bridge state directory. Explicit full Bridge-local data deletion must

remove each state file and its matching sibling key. Removing only a Project

registration does not remove these machine-wide ledgers.

Back Up or Restore Bridge State

Stop the Bridge before taking or restoring a backup. Copy each authenticated

state file and its sibling .key as one inseparable pair from the same

snapshot. Preserve mode 0600 on both files and restrict the backup itself to

the same trusted operator boundary. Do not upload the key to an untrusted

backup service, mix a state file with a key from another installation or key

generation, merge two ledgers, or restore only one half of a pair.

After restore, place both files at their original paths before starting the

Bridge. A missing, wrong, unreadable, or corrupt key, or a state/key pair from

different key generations, fails closed; the Bridge does not trust the old

idempotency results or dispatch the affected mutation. Authentication does not

detect rollback of both files to an older, internally valid backup. Before

restoring an older snapshot, the operator must resolve mutations created after

that snapshot and prevent their clients from retrying; otherwise those

mutation IDs are absent from the restored ledger and could execute again. If

the operator deliberately retires a ledger, the state and key must likewise be

retired together only after unknown Provider outcomes and delayed client

retries have been resolved.

Workspace snapshots are part of the authenticated Workspace ledger. The state

binds an exact digest manifest for both patch files, every copied file, and the

complete snapshot directory tree. A changed, missing, symbolic-link, special,

or unlisted entry fails restore and cleanup closed. Back up the complete

Workspace state/key pair and its manager-owned snapshots/ and worktrees/

directories from the same stopped-Bridge filesystem snapshot; do not combine

them from different points in time.

Request Relay-Side Data Deletion

If you used the maintainer-operated relay or review demo, you can request

deletion of relay-side metadata by contacting the app publisher using the

developer contact email shown on the Google Play store listing.

The publisher assigns a random request ID and a deadline no later than 30 days.

The Relay operations ledger contains that ID, lifecycle timestamps,

verification attestations, deleted-row counts, and an operator-keyed target

commitment. It does not store your email address, name,

machine/device/account identifiers, the commitment key, or the contents of your

request. The publisher keeps the temporary identity-to-request mapping in its

access-controlled support system while the request is open.

Use this email path if you need verified relay-side deletion, or if the app was

offline when you disconnected a paired machine.

Use this subject:

Mobile Agent data deletion request

Please include only the information needed to find your pairing, such as:

Do not send prompts, code, Kiro replies, bearer tokens, private keys, or other

secrets.

Data Deleted

After a verified deletion request, relay-side records associated with the

pairing are deleted, including:

account sync was used

Relay-owned account links and enrolled devices are removed transactionally.

The Supabase Auth identity, including its email address, is owned by Supabase

Auth and is deleted through a separate protected administrator workflow before

an account-targeted Relay request can be marked complete. After database

deletion, the operator resets the Relay runtime so already-authenticated

WebSockets cannot keep using process-memory routing state; only then is the

request marked complete.

Pairing requests are single-use and expire quickly even without a deletion

request. The Relay deletes expired requests at startup and on a recurring

retention pass. Completed deletion-operation receipts contain no target IDs or

personal details. A versioned, operator-keyed HMAC commitment binds each

request to the same target without storing that target or exposing the

commitment in receipts. Completed receipts become eligible for deletion after

at most 90 days and are removed by the next retention pass. Pending requests

are not auto-deleted and requests awaiting runtime reset are also not

auto-deleted; both remain visible to the daily overdue audit.

Device-only pairing recovery, safe-action retry, draft, Mobile Unblock, and

provider-breadth state is not stored by the Relay operator and must be cleared

through the app as described above. Bridge-local secret-interaction markers

must be cleared only after deleting the associated native Provider

conversation, or by an explicit full Bridge-local data deletion. Project

unregister alone intentionally retains them.

Bridge-local authenticated mutation and Task state is also outside Relay

operator storage. Full Bridge-local deletion must delete every selected

ledger together with its matching .json.key sibling; deleting the key alone

is not a complete deletion of Task or result data that remains in the state

file.

Data Not Available As Plaintext

Chat requests, agent replies and questions, structured execution timelines,

approval context and replies, task contents, file contents, snapshots, and

other app protocol messages are end-to-end encrypted between your mobile device

and bridge. The relay routes ciphertext and is not intended to store or read

those plaintext contents.

Retention

Deletion requests are processed within 30 days. Some operational logs or

backups may remain for up to 90 days for security, abuse prevention, or service

recovery, and then expire according to normal retention schedules. These logs

are not intended to contain prompts, code, Kiro replies, private keys, bearer

tokens, or one-time pairing tokens.

Maintainer procedure: Relay Data Deletion Runbook.