Privacy Policy for Mobile Agent

Effective date: 2026-08-14

Mobile Agent is an Android Open-testing developer tool that connects a mobile

device to local coding-agent sessions through a relay server. Codex app-server

is the only runtime with a strict native-admission ACK implementation; its

Android device qualification is still pending. Kiro, Claude, and Agy are

currently detection/read-side compatibility previews, not supported guarded

mobile-send paths. Kiro is not the product identity.

Data We Process

The app and relay process the minimum data needed to pair devices and route encrypted messages:

pasted pairing payload, the app keeps an encrypted, device-only record of the

random attempt ID, QR/paste method, start time, machine ID, relay URL, and

recovery stage. The one-time QR secret is not retained. After enrollment is

acknowledged, the record may temporarily contain the new device credential,

a rejected credential quarantined for revocation, and, during re-pairing, the

previous credential. This allows verification or revocation to resume after

an app restart or Bridge outage. A readiness attempt times out at 10 minutes,

but a candidate, quarantined, or previous credential is retained until its

Relay revocation is confirmed. After that, only a

content-free completion record is kept for up to 30 days to prevent duplicate

outcomes. If an existing journal is unreadable, corrupt, or from an

unsupported version, the app preserves it and disables new pairing changes

rather than discarding a credential that may still need revocation.

you start voice input for an instruction draft. In System mode, audio is

passed to the platform speech recognition service to convert speech to text.

In Whisper mode, the app records a temporary local audio file, downloads a

local Whisper model on first use if needed, transcribes on the device, and

deletes the temporary recording after transcription, stop, error, or

disposal. If the process is interrupted first, a later voice initialization

removes every regular crash-leftover recording whose filename exactly

matches the app's recording pattern, regardless of age and without following

links. The app does not send audio to the relay. Reviewed send remains the

default. In a separately

enabled Voice Fast Lane build, after you opt in for the Project, an ordinary

non-secret instruction to the visibly fixed existing Session may be sent

after a cancellation window and Bridge risk revalidation. Ambiguous,

secret-like, attached, command, offline, stale-target, and higher-risk input

is not Fast Lane sent. Leaving the app foreground while recording stops and

discards that recording attempt. Leaving during Fast Lane preflight or its

cancellation window permanently returns the recognized text to review;

returning to the app does not restart automatic send. Automatic send is available only

for an existing Codex app-server Session whose structured Provider-admission

acknowledgement can be checked. CLI, PTY, and CDP paths are rejected for

guarded mobile dispatch until a Provider-native exact-session admission ACK

is implemented and passes the device matrix; showing a reviewed-send UI does

not qualify those paths as supported.

The opt-in is stored only on this device under a hashed Host, pairing-device

credential, and Project scope. Earlier opt-in formats are not migrated.

Revoking a pairing first stores a local revocation marker that prevents a

late confirmation from re-enabling the old credential. A Project removal

observed during an authoritative refresh stores a removal marker and

requires a new opt-in if that Project is later re-added. Disconnecting a Host

removes its opt-in and Project-scope records. A content-free tombstone

containing only hashes of the Host and revoked random pairing credential

remains on the device until app data is cleared; it prevents delayed local

work from restoring consent for that credential. If required local cleanup

fails, the app retains the pairing so you can retry.

Secret agent questions disable voice input.

the device in encrypted form so they survive navigation or a restart. Draft

scope is a structured tuple of the applicable Host, Project, Session, task,

interaction, and question identifiers; delimiter characters inside one

identifier cannot select another target's draft or retry ID. The first draft

operation after upgrading from the older delimiter-based format deletes all

legacy-v1 encrypted drafts instead of guessing or migrating their targets;

unrelated app preferences are retained. An individual v2 draft is removed

after its successful send or an explicit discard. The shared

draft-encryption key is retained while at least one Bridge remains paired;

removing the final paired Bridge deletes all remaining drafts and that key.

Answers to questions marked secret are never persisted as drafts or durable

Inbox content.

While voice recognition is listening or transcribing, partial and manual

changes are not written to draft storage. Persistence resumes only after a

final result is classified as non-secret; a secret-like result is purged

rather than retained as a regular draft. Recognition errors and other

non-final exits keep an unclassified partial out of durable storage and

return it to explicit review or discard.

may retain a bounded previous instruction and latest Agent result so a user

can identify and reopen work without waiting for the full timeline. This is

a separate AES-256-GCM store, with an independent random key for each pairing

generation in platform secure storage. It keeps at most the title, bounded

checkpoint text, Provider/display state, source and last-seen revisions, and

timestamps for 30 days. It never stores a full transcript, attachment,

approval command or working directory, file diff, execution output, pending

question, or answer. The Bridge's durable secret-interaction marker is the

privacy authority: secret-tainted or privacy-unknown conversations retain

routing-only metadata with no title or checkpoint text. Protocol 2.0-2.10

previews are not persisted. Unpairing or credential replacement deletes the

old generation's key before removing its ciphertext, so delayed writes

cannot make that checkpoint readable again. Resume checkpoints remain local

to the device and are never included in Analytics, Push, or logs.

In a Push-enabled build, the app explains that notifications contain no work

content and asks for consent only after pairing, end-to-end encryption, and

Bridge readiness succeed. Native Firebase Messaging automatic initialization

remains disabled before this consent, including when Firebase Analytics

initializes Firebase. A private native startup guard resets any persisted

Messaging auto-init override before Firebase initializes. Phase A and review

manifests also disable the Messaging receiver, services, and init provider.

Flutter bootstrap then rechecks the distribution, consent, and cleanup state. A Push-disabled

distribution, missing consent, or pending cleanup keeps auto-init off and

deletes the native token; after pairing data loads, Relay cleanup is retried.

If permitted, Firebase supplies a token that the relay

stores for that paired device. Disabling notifications immediately removes

consent, turns Messaging auto-init off, stops token refresh, and attempts to

clear the relay registration and local Firebase token. If either cleanup is

temporarily unavailable, the app keeps a secure, content-free pending-cleanup

record and retries with the existing pairing credential at startup or

reconnect instead of reporting cleanup as complete. That record contains

machine/device routing IDs and cleanup state, but no Push token, credential,

Relay URL, or work content. Disconnecting a host also clears its registration;

local pairing credentials are retained when the Relay device revoke cannot be

confirmed so the user can retry.

enable it, the Bridge may send a bounded digest containing the Project name,

previous instruction, and latest result to a separate, tool-disabled call to

the same selected agent provider. This may use provider quota or incur

provider charges. Provider labels, conversation titles, current questions,

secret questions and answers, and source identifiers are excluded. Existing

conversations are not reviewed retroactively.

explicit instruction that looks secret, or an answer whose secrecy cannot be

determined because Timeline data is missing or invalid, the Bridge stores a

mode-0600, content-free marker containing only the Project ID,

conversation/cascade ID, and taint time. It contains no question, answer,

instruction, attachment name, value-derived hash, or provider output.

Unregistering a Project does not remove the selected provider's native

conversation history, so the marker survives unregistering and re-registering

the same root. It is removed only after the provider conversation is

authoritatively deleted or as part of an explicit full Bridge-local data

deletion. Durable idempotency records bind the safe request shape with a

fresh per-record salt and a machine-keyed HMAC; they do not persist the

answer, instruction, an ordinary value-derived hash, or a stable

cross-record token. The matching private machine key is stored in a

mode-0600 sibling .json.key file. Full Bridge-local deletion removes the

authenticated ledger and its matching key together. The marker prevents

later provider echoes from entering durable

Attention content or result review. If the marker cannot be written or an

existing marker store is corrupt or unsupported, the Bridge fails closed

rather than forwarding or reclassifying potentially secret content.

Secret-like initial Conversation, Task, and Schedule text is rejected

because those surfaces may persist the original text.

Bridge restart is stored as a version-2 envelope containing a fresh random

salt, a machine-keyed HMAC authenticator, content-free risk reason

fingerprint, policy version, and approval time. The envelope does not store

the instruction again, an unkeyed instruction hash, the machine secret, or a

stable target token. Repeating the same confirmation produces an unlinkable

authenticator. Legacy version-1 unkeyed-hash envelopes are rejected.

values remain inside the end-to-end encrypted app connection. Optional

user-declared budgets, reset times, numeric request usage, and random

reservation IDs are stored on the paired Bridge in a mode-0600 local state

file so request limits can be enforced before dispatch. The routing

suggestion RPC receives only structured Provider capacity, capability,

availability, and budget state; it does not receive the instruction,

transcript, prompt, code, Project name, or conversation content. Selecting a

suggestion does not dispatch work.

aggregate app-session and engagement data and a small allowlist of

eleven content-free events: pairing_result, attention_opened,

agent_action_result, unblock_action, mobile_unblock, push_signal,

provider_breadth_weekly, command_center_weekly_active,

voice_instruction_result,

weekly_outcome_summary, and capacity_coverage_weekly. The final four

command-center events

require a separate command-center metrics build gate and are not mixed into

the established closed-test evidence dataset.

A review transition, “cancel and review,” or recoverable dispatch failure is

not recorded as a terminal while the same voice instruction can still be

sent; one terminal is recorded only after acknowledgement, explicit

discard/clear, or abandonment. Likely-secret voice attempts produce no

custom event.

Values are fixed categories, bounded durations or aggregate counters, or

fixed capacity buckets. Custom events never

include prompts, transcripts, answers, agent replies, code, Project or

provider names, machine/device/Project/provider/chat/Attention/request/

interaction identifiers, relay URLs, credentials, or clientMutationId.

Interactions containing a secret question produce no custom event, including

no flag revealing that the interaction was secret. The review build disables

Firebase Analytics collection itself. Firebase may process app/device

identifiers needed to provide Analytics and derive approximate location from

a masked IP address. The app does not request or collect precise location.

on the device in encrypted secure storage. Pending records expire after the

10-minute confirmation window; deduplication tombstones expire after 30 days.

Raw correlation and routing identifiers are never sent as Analytics

parameters.

separate encrypted, device-only retry store. Approval attempts use a SHA-256

fingerprint of routing/request/decision fields. For choice-only input,

normalized question IDs and answer values are processed only in memory with

a random per-install HMAC key; only the resulting opaque binding is included

in the SHA-256 retry fingerprint. The store contains fingerprints, a random

retry-stable mutation ID, update times, and the HMAC key—not raw answers,

question text, commands, approval context, or other work content. The entry

is removed after explicit success or known failure. It is retained only when

delivery is unknown, for no more than 30 days, and is removed for a Host when

that Host is disconnected. An unknown choice created before answer binding

is not rebound or retried and fails closed until it expires. Removing the

final Host also removes the HMAC key. Corrupt or unsupported state is not

replaced with an empty store; the affected action is disabled until the

state can be handled safely. Neither the fingerprint nor mutation ID is sent

to Firebase.

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

set of raw provider IDs that acknowledged eligible non-secret actions. Raw

provider IDs and timestamps remain on the device and are never sent to

Firebase; only a 1, 2, or 3_plus count bucket is emitted. Closed-test

state is deleted after a successful end-of-window report and no later than

35 days after pairing or Activation. ISO-week state in other distributions

is deleted no later than seven days after that week. Removing the final

paired Host clears all remaining provider-breadth state immediately.

ENABLE_COMMAND_CENTER_METRICS gate is enabled, the app may send one

parameter-free active-pairing event per UTC week; bounded aggregate integer

counts for accepted outcomes, accepted Providers, interventions, low-risk

outcomes, and low-risk outcomes completed without another intervention;

bounded intervention and human-blocked idle seconds; bounded instruction

latency milliseconds; fixed low-risk/risk/outcome/edit/confirmation

categories; and

bucketed Capacity coverage and utilization. The free-form weekly note,

Provider identities, instruction text, transcript, and per-session

correlation are neither accepted by the event schema nor sent to Analytics.

Weekly duration values are whole-minute estimates entered by the user and

converted to seconds; the app does not passively inspect work content to

derive them.

and short-lived authentication tokens to discover hosts already linked to

the same account. QR pairing remains available without an account. Account

data is not enabled or collected in distributions built without the account

backend configuration.

How We Use Data

We use this data to:

closed-test engagement.

enabled and you choose to sign in.

Data Sharing

We do not sell user data.

If you use a relay operated by the project maintainer, connection metadata is processed by that relay. Encrypted app payloads remain ciphertext at the relay. If you self-host the relay, your data is processed by your own infrastructure instead. Instructions and any photos you attach are processed by the agent provider you select after they reach your paired Bridge; that provider's terms and retention policies apply.

Firebase Analytics processes the usage analytics described above on our behalf.

Firebase Cloud Messaging processes Push tokens and notifications only in

Push-enabled distributions after opt-in. The configured account service

processes email and authentication tokens only in account-enabled

distributions. We do not use these services to sell data or identify the

contents of your work.

Data Retention and Deletion

Pairing requests are single-use and expire quickly. Registered device and

machine metadata remains until it is removed from the relay database. On the

mobile device, "接続を解除" first asks the Relay to revoke any pairing

candidate, quarantined, or previous credential and then the selected active

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

confirmed, the app shows the removal as pending and retains only the local

pairing credentials needed to retry; it does not report deletion as complete.

After confirmation, it removes the selected paired-machine record, local active

key, pairing attempt and transient machine-linked tombstone records, safe action

retry IDs, and encrypted Mobile Unblock correlation records for that Host. The

content-free hashed Fast Lane pairing-revocation tombstone described above is

retained until app data is cleared so delayed work cannot restore old consent. All

encrypted drafts and their draft-encryption key are cleared only when

this completes removal of the final paired Bridge. If another pairing remains,

the shared draft store is not cleared; unfinished drafts remain until

successful send, explicit discard, or final pairing removal. Secret answers

are cleared on success, failure, dismissal, and backgrounding. Removing the

final Host also clears the device-only successful-pairing/Activation timestamps

and raw provider-ID set used for provider-breadth measurement. A Bridge secret

interaction marker is removed only after its Project is durably deleted.

Optional account and Host-link metadata can be deleted through the process described on the

Data Deletion page.

To request deletion of relay-side metadata for a maintainer-operated relay, contact the relay operator listed on the app's Google Play store listing.

Security

Mobile Agent uses device key pairs and an ephemeral X25519 handshake for end-to-end encrypted application messages. Secrets are not intentionally written to structured logs. You should use only HTTPS relay URLs in production.

Children

Mobile Agent is intended for software developers and is not directed to children.

Trademark Notice

Mobile Agent is an independent companion tool being validated for Kiro read-side compatibility. It is not affiliated with, endorsed by, or sponsored by Amazon Web Services. Kiro is a trademark of Amazon Web Services, Inc. or its affiliates.

Changes

We may update this policy as the app changes. Material changes will be reflected in the published policy before release.

Contact

For privacy questions, contact the app publisher listed on Google Play.