# AI Consent And Account Deletion In LikeClaw How LikeClaw, Fulldive's AI agent app, handles AI consent, scoped permissions, account deletion, and the user data lifecycle. _Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below._ Trust in an **AI agent app** is built in two places: the consent surface where a user agrees to what the agent can do, and the deletion path where a user can walk away. This post is a direct look at how LikeClaw, Fulldive’s mobile AI workspace, handles both. It is anchored on commit `d3457d6`, which simplified AI consent and added account deletion, and on the Connections screen from `a8aef32`, which is where scoped permissions live. If you have not seen the product history, [LikeClaw: from chat dashboard to mobile AI workspace](/content/post/likeclaw-chat-dashboard-to-mobile-ai-workspace/index.html) sets the stage. This post is the trust-and-privacy companion. ## Why consent has to be simple An **AI agent app** asks for a lot. It reads files in a workspace, connects to external accounts, runs skills that invoke tools, and displays generated images. Each of those is a separate thing to consent to, and bundling them into a wall of legal text helps nobody. Commit `d3457d6` went the other direction. It **simplified AI consent** and paired it with **account deletion**. Two details matter about that pairing: - Simplification means fewer and clearer categories of consent, not fewer disclosures. The user still needs to know what the agent is doing; they just need to know it in readable language. - Shipping deletion with consent signals that consent is revocable. If you can change your mind — all the way, up to and including deleting the account — the initial consent surface can afford to be simpler. The philosophical frame is that consent is an **ongoing conversation**, not a one-time checkbox. The UI should support that; `d3457d6` is the first large step in that direction. ## Scoped permissions via the Connections screen Consent in the abstract is one thing. Consent that maps to real OAuth scopes is another. Commit `a8aef32` introduced the **Connections screen**, which is where external integrations are authorized. Two examples make the model concrete: - A Gmail integration uses OAuth scopes from the catalog documented at [Gmail OAuth scopes](https://developers.google.com/gmail/api/auth/scopes). Read-only scopes are meaningfully different from send-and-modify scopes, and the Connections screen is where that difference is exposed. - A skill that needs file access operates through the workspace’s virtual file system — see [skills and virtual files in LikeClaw](/content/post/skills-virtual-files-likeclaw/index.html) — rather than through the device file system. The user consents to the workspace, not to “all my phone’s files.” The principle: **grant the narrowest scope that lets a skill do its job**. Revoke scopes you no longer use. The Connections screen is designed to make both actions visible. ## Account deletion as a first-class feature A fair number of apps treat account deletion as a support ticket rather than a product feature. `d3457d6` pushed it into the product. Practical consequences: - **Discoverable location.** Deletion lives inside the app, not buried in a web portal. Apple and Google both require this for apps that support account creation; Apple’s App Store guidance has been explicit for several years. Shipping it in-app closes a compliance loop and an ethical one at the same time. - **Clear scope.** Deletion removes the account and the associated user data. Users deserve to know what that means: their workspace files, their chat history, their connections, their billing records insofar as the platform allows their removal. - **Irreversible by design.** Account deletion is supposed to be final. Any “undo” mechanism on deletion weakens the promise. We would rather make the deletion step explicit and clear than soft-delete silently. Billing records are a nuance. Receipt data often has to be retained for accounting or platform-required reasons — see [billing and StoreKit 2 in a mobile AI app](/content/post/billing-storekit-mobile-ai-app/index.html). Retention that is legally required should be disclosed; retention that is not should not happen. ## User data lifecycle: a plain-language walk A walk through the data lifecycle of an average LikeClaw user, using the repository’s own surfaces: 1. **Sign-up and sign-in.** Token-preserving login from `5682625` keeps the session alive across restarts, so the app does not ask for credentials on every launch. 2. **Consent.**`d3457d6` presents the simplified consent surface. 3. **Workspace use.** The chat (`9632105`, `c3001bf`), the VFS and skills (`2970709`), tool calls (`882aa78`), and the file-changes card (`81420bd`) are all in active use. Background polling (`09ee58f`) keeps state fresh, and the inbox (`bf94935`) captures events outside active conversations. 4. **Connections.**`a8aef32` mediates any external integrations with scoped OAuth. 5. **Billing.** Credits and subscriptions (`7cf67c3`, `8a146d7`, `0b9f7db`) run through platform in-app purchase with StoreKit 2 signed transaction handling on iOS; see [billing and StoreKit 2 in a mobile AI app](/content/post/billing-storekit-mobile-ai-app/index.html) and Apple’s [StoreKit reference](https://developer.apple.com/documentation/storekit) for detail. 6. **Revocation and deletion.** Consent can be revisited; individual Connections can be revoked; the whole account can be deleted via the path added in `d3457d6`. The lifecycle is not complicated in principle. The work is in making each step visible and reversible. ## Why this is Fulldive’s E-E-A-T anchor for LikeClaw Fulldive’s broader philosophy, covered in [the Fulldive company story](/content/post/fulldive-company-story/index.html) and in [what is Fulldive](/content/post/what-is-fulldive/index.html), is to ship focused apps that do one thing well. The catalog — [Wize AdBlock VPN](/content/project/adblock-vpn/index.html), [WizeUp browser](/content/project/fulldive-browser/index.html), [Fulldive VR](/content/project/fulldive-vr/index.html), [One Emulator for Game Consoles](/content/project/one-emulator-for-game-consoles/index.html), among others listed on the [apps page](/content/projects/projects-list/index.html) — reflects that. An AI agent app sits at the far end of the trust spectrum for that catalog. It reads more, writes more, and reaches further than, say, a QR scanner. That is why consent and deletion are the trust anchor, not nice-to-haves. The related framing in [what a mobile AI agent can responsibly automate](/content/post/what-mobile-ai-agent-can-responsibly-automate/index.html) covers why oversight matters in use; this post covers how consent and deletion make that oversight meaningful. ## Limits and safety Some explicit limits on what consent and deletion in LikeClaw are, and are not: - Consent is a user interface built on top of a product. A consent dialog does not, by itself, prove the agent will behave well. See [what a mobile AI agent can responsibly automate](/content/post/what-mobile-ai-agent-can-responsibly-automate/index.html) for the oversight framing that has to accompany consent. - Account deletion removes the account. It does not retroactively change what was shared with a third-party integration while that integration was connected. If you gave a skill read access to an external mailbox and an action was taken there, deleting your LikeClaw account will not unsend those actions. Revoke connections at their source where needed. - Simplified copy is not legal advice. The Privacy Policy and Terms linked from the [FAQ](/content/pages/faq-page/index.html) and [about us](/content/pages/about-us/index.html) pages are the authoritative statements. The simplified consent UI is meant to help, not replace them. - We do not claim LikeClaw is uniquely private or uniquely safe. We claim specific, verifiable behaviors backed by commits. Assume responsibility for accounts you connect, and prefer narrower scopes over broader ones.