When a mobile app changes the privacy contract

Cursor’s mobile app launched with a requirement that surprised some existing users. To use it, they had to move from Cursor’s legacy privacy mode to its newer privacy mode, which allows Cursor to store some state needed by cloud agents.

One user described the change as irreversible in a Hacker News thread. A Cursor employee later clarified in the same discussion that users who do not want cloud agents can remain on the legacy mode and that support can revert the migration. Cursor also said it was updating the app to explain the choice more clearly.

That correction matters. The original claim that the app rewrote iOS-level settings was not supported. The underlying product problem remains.

An account setting with device-sized consequences

The setting at issue belonged to the Cursor account, not the operating system. But the choice was still consequential. Cursor’s current data-use explanation says that its privacy mode prevents training on customer data and uses zero-data-retention agreements with model providers, while allowing temporary encrypted storage needed for features such as cloud agents. The legacy mode offered a stricter boundary at the cost of those features.

A mobile app should not make that trade appear incidental. If a user previously chose the stricter mode, enabling mobile access should explain what changes, why it changes and how to go back before asking for consent.

The tooling layer has stopped asking

The episode is useful because it exposes a pattern across agent products. New capabilities frequently depend on broader access or longer-lived state. A cloud agent needs enough context to continue when your laptop is closed. A desktop agent needs files and tools. Memory needs something to be retained.

Each feature can be reasonable on its own. The problem appears when the product treats the expanded trust boundary as an implementation detail.

On desktop, my agents run on dedicated hardware. I can snapshot the environment, limit the accounts available to it and inspect what happened. That is not perfect isolation, but the boundary is one I chose.

On mobile, the user has fewer ways to inspect or contain the system. That makes clear consent more important, not less.

Local-first means the device comes first

This is why I run my own stack. Not because I’m paranoid. Because the moment you let a third-party tool own your device configuration, you’ve ceded the one thing that makes local-first computing meaningful.

Local-first is not only a statement about where a file sits. It is a statement about who can change the terms of access. Cloud features can still belong in a local-first product, but the transition should be explicit and reversible.

Cursor responded to the immediate complaint and clarified that support could restore the previous mode. The better product response is to make support unnecessary: show the old boundary, the new one and the consequences of the choice in the interface itself.

When an agent product adds a convenient new surface, I now ask a less exciting question first: what had to become persistent, remote or more privileged to make this work?