How account-synced preferences can hijack Claude Desktop's local tools

What is this?

In research published in early July 2026 — covered by The Register on July 1, 2026 and detailed by Pentera Labs under the name AI Double Agent — red teamers demonstrated that a widely used desktop AI assistant’s synced settings can be turned into a persistent prompt-injection channel. The target is the assistant’s Personal Preferences field: a user-configurable prompt that stores tone, workflow and behavioural guidance, and that is automatically synced across every device and session tied to the account, including the desktop app.

The finding is not a memory-corruption bug or a remote unauthenticated flaw. It is a trust-boundary problem: a piece of account-controlled configuration that the assistant treats as instructions is also a place an attacker can write to once they hold the account. The researchers reported it to the vendor in November 2025. The vendor acknowledged it but declined to classify it as a security vulnerability, arguing that preferences, skills and connectors are features designed to let the assistant act — so no CVE was assigned. That disagreement is itself the interesting part, and it is why we treat this as a defensive lesson rather than a patchable defect.

How it works

The chain has three conceptual stages, and none of them requires malware delivery or a phishing email to the victim.

Account access  -> attacker reaches the victim's assistant account
Stored payload  -> instructions written into synced Personal Preferences
Sync + trigger  -> desktop app loads them and drives local tools

Initial access in the demonstrated scenario came from a third-party service that aggregated many users’ inboxes; weak authentication there let the researchers pivot into associated accounts through magic links and password resets. With the account in hand, they placed an encoded instruction blob into Personal Preferences. Written as an opaque string rather than plain-language commands, it is easy to miss in a casual review — the point is to blend into a field users rarely audit.

Because the field syncs, the next time the victim opens the desktop app the injected content loads silently as part of the assistant’s standing guidance. From there the payload’s logic is conditional. If a command-capable extension — the writeups name a local command-execution tool — is already installed, the assistant can be steered to invoke it in the background while still answering the user’s visible questions, creating a loop where each interaction can fetch and run updated instructions from attacker infrastructure. If no such tool is present, the payload switches to social engineering: it makes the assistant itself display a realistic, workflow-shaped error that urges the user to install a specific extension “to fix the problem.” The assistant, trusted by the user, becomes the phishing layer.

We are deliberately not publishing the payload or its encoding. The mechanism — stored, synced configuration is treated as trusted instructions, and connected tools inherit that trust — is what matters here.

Why it matters

This is a concrete instance of the “lethal trifecta”: untrusted content, a tool-capable agent, and the ability to reach the outside world. The novelty is where the untrusted content lives. Most prompt-injection coverage focuses on content pulled in at runtime — a web page, a document, a tool result. Here the malicious instruction is parked in the user’s own account settings and delivered by the vendor’s sync mechanism, which makes it persistent and portable across devices.

The blast radius depends on the victim. On a developer or DevOps machine, command execution can mean harvested SSH keys, cloud credentials, kubeconfigs and CI/CD tokens, and a path toward lateral movement into production. On a non-technical endpoint, the same trust can be turned toward session hijacking, credential theft from the browser, and impersonation on collaboration tools. And the vendor’s position — that this is expected functionality — means defenders cannot wait for a patch to close it. If your threat model includes account takeover, synced assistant configuration is now part of your attack surface.

Defenses

Protect the account first. The whole chain begins with someone else reaching the assistant account, so multi-factor authentication, careful scrutiny of third-party inbox aggregators and OAuth grants, and monitoring for account-takeover signals are the highest-leverage controls.

Treat synced configuration as untrusted, security-relevant state. Personal Preferences, memory, skills and connector definitions should be reviewed periodically and after any suspected account compromise; an opaque encoded blob in a preferences field is a red flag, not a quirk.

Constrain what tools can do. Apply least privilege to command-capable extensions — install local code-execution tools only when genuinely needed, and sandbox them. Require explicit, per-action human approval for tool calls rather than allowing silent background execution, so a poisoned instruction cannot quietly drive the shell.

Assume the assistant can be turned into a phishing surface. A trusted assistant recommending that you install a particular extension is now a vector: verify any such prompt out of band before acting on it.

Add defense in depth around the endpoint. Restrict outbound egress from workstations that run tool-enabled assistants, keep EDR in place, and practice secrets hygiene — short-lived tokens, no long-lived SSH or cloud credentials sitting in plaintext home-directory paths.

Status

Item	Detail
Disclosure	Reported to the vendor in November 2025; public writeups early July 2026 (The Register, 1 Jul 2026)
Vendor position	Preferences, skills and MCP connectors are considered features designed to execute code; classified as expected functionality, no CVE assigned; enhancements said to be on the roadmap
Precondition	Requires prior account access; not a remote unauthenticated flaw
Nature	Trust-boundary / stored prompt-injection issue enabling local tool execution and persistence via synced configuration
Fix status	No patch expected by design — mitigation is account security, least-privilege tooling, and human-in-the-loop approval