Claude Code macOS OAuth Tokens Exposed to Same-User Apps

The important finding is not that Claude Code stores credentials in Keychain. Anthropic’s own documentation confirms that it does, while Linux and Windows versions use a

file within the user profile. The problem identified by Silverfort is the access rule applied to the macOS Keychain item: the credential is reportedly created through Apple’s general-purpose

utility rather than being tied to Claude Code’s own signed executable.

That implementation choice turns macOS Keychain from a per-application safeguard into a same-user secret store. The practical consequence is credential theft after initial endpoint compromise, without the extra user-interaction barrier that Keychain is supposed to provide for a separate application requesting a secret.

The Keychain entry is protected by the wrong identity​

Silverfort’s July 28 report says Claude Code CLI creates its Keychain item through

, Apple’s signed command-line Keychain utility. Under the default access-control behavior described for that utility, the trusted application recorded against the item is the

binary itself, not the Claude Code binary that ultimately needs the secret.

That distinction is more than implementation trivia.

is a system tool available to programs operating in the logged-in user’s context. If the Keychain item trusts that utility, a different same-user process can invoke it and satisfy the item’s access rule. The process does not need administrator rights, a separate Keychain password, or user approval.

Silverfort says the resulting item contains Claude Code’s OAuth bundle, including a short-lived access token and a refresh token. The refresh token is the more durable concern: it can be exchanged for fresh access tokens until it expires or is revoked. The firm also says connected Model Context Protocol, or MCP, credentials and plugin secrets may be present in the same stored data, expanding the exposure beyond the Claude account itself.

Anthropic’s documentation confirms the underlying credential-storage split across operating systems: macOS uses Keychain, while Windows stores credentials at

and Linux uses

with mode

. The published documentation describes the macOS location as encrypted, but it does not explain the Keychain item’s application access controls.

Silverfort tested the behavior on Claude Code CLI 2.1.185 and says it reported the issue to Anthropic through HackerOne on June 25. According to Silverfort’s disclosure timeline, Anthropic classified a tightened Keychain ACL as a defense-in-depth hardening improvement rather than a vulnerability under its same-user threat model. No public Anthropic security advisory or changelog entry reviewed for this report identifies a released remediation for this specific Keychain access-control design.

Same-user code execution is still a meaningful attack boundary​

Anthropic’s apparent position rests on a familiar operating-system assumption: programs running as the same user can generally access that user’s data. That is often true, but it misses why Keychain exists in the first place. macOS Keychain can apply a second boundary by requiring authorization when one application requests a secret that belongs to another.

Silverfort contrasts Claude Code CLI with Claude Desktop, which it says protects its Keychain-backed material with an app-specific authorization model. If that comparison is accurate, Anthropic already has a working example of the protection the CLI lacks on the same operating system.

This matters particularly for AI coding tools because they run unreviewed project code, install packages, execute hooks, launch shells, and connect to external tools. A malicious

script, poisoned developer dependency, hostile IDE extension, browser compromise, or an agent persuaded to execute a malicious command does not need to gain root access to make this weakness useful. It needs only to run in the developer’s account — the same account that has access to source trees, cloud credentials, Git providers, and MCP-connected systems.

The exposure is therefore best understood as a credential-persistence amplifier. An attacker who already has code execution can often steal files, browser cookies, SSH keys, or environment variables depending on the machine. Claude Code’s Keychain item is supposed to make the OAuth token bundle harder to obtain. Silverfort’s finding says the present configuration does not add that protection on macOS.

It also changes incident response. Cleaning a malicious process off a Mac is not enough if the process already copied a refresh token. Teams investigating suspected endpoint compromise should consider invalidating Claude Code sessions and requiring a fresh sign-in, rather than assuming that removing persistence from the host ends the attacker’s access.

Do not confuse routine Keychain access with a clean bill of health​

The submitted report attributes endpoint observations to Elastic Security Labs, including shells launched beneath Claude Code that access Keychain and a reported investigation involving a suspicious tunnel and LaunchAgent persistence. However, no matching Elastic Security Labs report corroborating those Claude Code-specific claims could be located in the public Elastic research record reviewed for this article. Those details should not be treated as independently confirmed evidence of a normal Claude Code process tree or a documented Elastic incident.

That absence matters because it is easy to create weak detection logic around a compelling process-chain story. A command-line coding agent launching a shell is ordinary behavior; a shell touching Keychain can also be ordinary behavior; and an Apple-signed

binary is plainly legitimate. None of those facts establish that the activity is safe.

Security teams should avoid a blanket rule that either suppresses all Claude Code Keychain access or automatically treats every access as credential theft. The meaningful questions are contextual:

• A Keychain read initiated by the expected Claude Code installation during an interactive session is lower priority than an unrelated unsigned process making the same request.
• A process launched from writable temporary directories, a browser download folder, or an unfamiliar project dependency deserves far more scrutiny than a signed binary in its expected application path.
• A Keychain-read event followed by outbound network activity, creation of a LaunchAgent, shell-profile changes, or new remote-access tooling deserves escalation as a combined sequence.
• Reuse of the same Claude OAuth session from a separate device or unfamiliar network is the strongest downstream signal, because it indicates the secret may have left the original workstation.

The vendor-signed parent problem is especially relevant to endpoint detection. An attacker can hide behind legitimate binaries and shells precisely because developer tooling calls them routinely. Trust should be attached to the full process ancestry, binary signature, launch path, command line, user interaction, and subsequent behavior — not simply to the presence of

,

, or Apple’s Keychain utility in the tree.

Windows administrators have a different storage problem​

This specific Keychain ACL issue is confined to macOS. Windows installations of Claude Code do not use Apple Keychain, so Windows endpoints are not exposed to the same flawed application-trust relationship. Anthropic says Windows credentials are stored in

, inheriting the protections of the user’s profile directory.

That arrangement keeps other Windows accounts from casually reading the file, but it does not make it resistant to malware already executing as the developer. The same basic boundary applies: a process running under Alice’s Windows account can generally read files Alice can read. In other words, Windows avoids the macOS Keychain design flaw, but it has a more visible token target on disk.

For Windows fleets, EDR rules should treat reads of

by unexpected processes as credential-access telemetry, especially when the requesting executable is unsigned, recently downloaded, spawned from a temporary directory, or connected to an unusual destination. Administrators should also account for the

environment variable, which Anthropic documents as a way to relocate the credential file; a detection rule that watches only the default profile path can miss a deliberately moved configuration.

The secure operational pattern is to keep AI coding agents away from production credentials where possible. Use separate accounts, scoped access tokens, short-lived cloud credentials, isolated development environments, and narrowly authorized MCP services. An OAuth token that grants access only to a development sandbox is still a problem when stolen, but it is far less damaging than one linked to production source repositories, ticketing systems, deployment tools, or internal knowledge bases.

A cited CVE does not belong to Claude Code​

The submitted report also links this development to CVE-2026-27487, describing it as an earlier Claude Code command-injection fix. The public vulnerability record does not support that attribution.

NVD identifies CVE-2026-27487 as a vulnerability in OpenClaw, a separate personal AI assistant project, affecting versions 2026.2.13 and earlier. Its description mentions a “Claude CLI keychain credential refresh path,” but the listed references point to the OpenClaw repository and its 2026.2.14 release, not Anthropic’s Claude Code repository. Treating that CVE as a Claude Code vulnerability is a material conflation of two different products.

That correction is operationally important. Security teams should not use CVE-2026-27487 as evidence that updating Anthropic Claude Code fixes the Keychain design issue described by Silverfort. The reported Keychain weakness has no CVE in the public records reviewed here, and Silverfort says Anthropic has framed a future ACL change as hardening rather than a mandatory security patch.

For Mac administrators, the actionable conclusion is straightforward: treat a Claude Code OAuth login as a durable credential with access that may extend into connected MCP services, and assume a same-user compromise can extract it under the currently documented design. For Windows administrators, protect the corresponding credential file as a high-value user-profile secret. In both cases, the endpoint control that matters most is preventing untrusted code from running in the developer’s session before it reaches the token store.