> ## Documentation Index
> Fetch the complete documentation index at: https://docs.semgrep.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Semgrep Guardian authentication

> How Semgrep Guardian signs in, where credentials are stored, and why shared tokens are discouraged.

How you sign in depends on which coding agent you use. Claude Code and Codex are the recommended setups.

<Tabs>
  <Tab title="Claude Code and Codex">
    The Claude Code and Codex plugins use Semgrep's hosted remote server and authenticate through OAuth, so developers don't need to install or run the Semgrep CLI. Each developer completes a one-time browser sign-in when they first use the plugin. Semgrep refreshes access tokens automatically, so developers rarely need to sign in again.

    ### Credentials

    OAuth credentials are written to `~/.semgrep/guardian.yml` when you sign in through the Claude Code or Codex plugin.

    At startup, Guardian fetches its default authentication method from Semgrep's remote server. OAuth is the default for users who aren't yet signed in. This setting is global and not configurable per user.

    If OAuth credentials are present in `guardian.yml`, Guardian uses them instead of any API token in `~/.semgrep/settings.yml`.

    ### Scans running under an unexpected account

    If you're switching from a local CLI setup to the Claude Code or Codex plugin, an existing OAuth session in `guardian.yml` takes precedence over CLI credentials in `settings.yml`. If scans run under a different account than you expect, check which file contains active credentials. Use [`semgrep logout`](/getting-started/cli#log-out) to remove CLI credentials from `settings.yml`.

    To sign in with the legacy API-token method in Claude Code or Codex, ask the Guardian MCP to sign in to Semgrep using the legacy method.
  </Tab>

  <Tab title="Other coding agents">
    Other integrations run Semgrep through a locally installed CLI. Each developer signs in with `semgrep login`, which opens a browser-based sign-in flow. See [Install the Semgrep CLI](/semgrep-guardian/install-cli) only if you need one of these setups.

    ### Credentials

    Credentials are written to `~/.semgrep/settings.yml` when you sign in through `semgrep login` or set an API token manually. This is the same file the Semgrep CLI uses. If you're already signed in through `semgrep login`, Guardian can use those credentials.
  </Tab>
</Tabs>

## Shared tokens and service accounts

Shared API tokens and service accounts are not recommended. Each developer authenticates individually, through OAuth in Claude Code or Codex, or with `semgrep login` elsewhere, so Semgrep can associate activity with the correct user.

Semgrep discourages sharing app or API tokens across a team because:

* Revoking a shared token affects every user who depends on it.
* Shared credentials are rate-limited as a single user, which can throttle scans when many developers run Guardian concurrently.
* An API token in `settings.yml` is only used when no OAuth session exists in `guardian.yml`. Prefer OAuth for enterprise deployments.

Prefer OAuth. When developers can't complete a browser sign-in, deploy Guardian with a read-only token. Semgrep supports this shared credential on Semgrep Enterprise. For more information, see [Deploy with a read-only token](/semgrep-guardian/enterprise-deployment#deploy-with-a-read-only-token-semgrep-enterprise-only).

## Related pages

* [Choose your setup](/semgrep-guardian/choose-your-setup)
* [Deploy across your organization](/semgrep-guardian/enterprise-deployment)