Are Claude Code mods safe with a Sume API key in your env?

Only as safe as the mod's author: Claude Code's own docs say a mod is code that runs with your permissions, can read environment variables and settings files including an API key kept in either, and is not sandboxed. If SUME_API_KEY is exported in the shell that starts Claude Code, an installed mod can read it. The practical answer is to install mods only from authors you trust, read what a mod asks for before installing, and keep long-lived Sume credentials out of the places a mod is documented to reach.

Everything about mods below comes from Claude Code's mods overview and organization guide, read 2026-10-03. Everything about Sume credentials comes from Sume's docs.

What can a mod reach?

Claude Code's overview lists six things a mod can do once it loads. The table maps each one to the Sume credentials and data that a developer typically has within reach on the same machine.

Which Sume credential is exposed to that?

An API key is the exposed one. Sume's OAuth and API keys page says an API-key session sees the full hosted tool set, including paid tools, so a leaked key can submit work against your wallet. The CLI security page tells you never to print or commit SUME_API_KEY or the local config.json, which is the same file a mod with file access could read.

An OAuth session is different in two documented ways. The token is not a Sume API key, and Sume's docs say not to store OAuth tokens in CLI config or paste them into prompts. And the default grant is mcp:read, which sees read-only tools; paid and write tools stay hidden unless you turn Write on at consent. Claude Code's pages do not say where it stores an MCP OAuth token or whether a mod can read it, so this post does not claim either.

What should I do before installing a mod?

Run claude plugin validate on the mod's directory. Per the organization guide, its output has a hooks: line with the events the mod handles and a calls: line with the mods API methods it uses, and an env reads: line names each environment variable the code reads. Claude Code refuses to load a mod that uses the API in a way the command cannot read, so the list is meant to be complete. A mod that reads the environment and also makes network requests deserves a close look. Reviewing a mod's output before install walks through the lines.

# 1. Read what the mod asks for, without running it
claude plugin validate ./some-mod

# 2. Try it once with nothing else loaded
claude --safe-mode

# 3. Connect Sume with OAuth, not an exported key
claude mcp add --transport http sume https://mcp.sume.com/mcp
claude mcp login sume

What else lowers the risk?

These steps combine Claude Code's own switches with Sume's credential advice. None of them makes an untrusted mod safe; they reduce what an installed one can find.

• Use OAuth with Write off for read-only work such as tools_list, catalog_list, or jobs_list; nothing in that session can submit a paid job.
• Keep API keys for automation that needs them, in a secret manager rather than an exported variable in an interactive shell, and rotate a key if it appears in logs or chat history, as Sume's docs advise.
• Start Claude Code with --safe-mode to run without installed mods, or set disableAllHooks to stop every installed mod; a plugin's skills and MCP servers still load under disableAllHooks.
• On a managed fleet, let administrators set allowManagedModsOnly, which refuses every mod a user brings. See the managed-settings post for what it leaves alone.

Is the mod guard enough?

Claude Code loads a built-in guard, sec-default, ahead of user mods on machines with managed settings or a Team or Enterprise sign-in. It protects what your organization manages, and the admin page states that everything else is allowed. It also says deny rules do not cover a mod's own file and process calls: with Read(.env) denied, a mod can still read that file with $.fs.read. So a deny rule on your env file is not a defense against a mod; keeping the mod out is.