Last updated: June 2026
Godmode runs inside Claude Code, on your machine, with your files. That is exactly the position where you are right to be suspicious of any third-party tool. This page documents precisely what each piece of Godmode installs, what it runs, and what (if anything) it sends over the network, so you can verify the answer yourself instead of trusting a marketing claim.
SKILL.md instruction file, and the paid skills also
ship plain-text helper scripts (Node and shell) that Claude runs
locally as part of the protocol. There are no compiled binaries,
nothing minified, nothing obfuscated. You can read every line before it
runs, and because the scripts run under Claude Code's normal permission
model, you approve each command before it executes.
godmode-mcp npm package is the only
component that makes network calls on your behalf. Every call it can
make is listed below with the exact endpoint and request body. No file
content ever leaves your machine through it.
Persona research kept asking the same question: what actually executes, broken down by Markdown versus scripts versus hooks versus the MCP. Here it is.
SKILL.md plus phase and
reference docs). Plain text that instructs Claude. It makes no network
calls and does nothing by itself. blog-post-GM is
only this: it ships markdown and templates, zero scripts.
runner/,
scripts/, phases/). Plain-text Node and shell
scripts that Claude runs locally as part of a skill's protocol (for
example godmode-lite's runner/ CLI,
one-shot-scripts' runner gates,
godmode-evolution's scoring and mutation engines). They run
under Claude Code's permission model, so you see and approve each
command. They are readable source, not binaries.
godmode-mcp client (a separate npm
package). The only component that talks to the network in normal use,
and only to discover, entitle, and download skills. It is
not bundled inside the skill zips: you install it yourself.
Full behavior is in the next section.
PreToolUse, PostToolUse,
SessionStart, no edits to settings.json).
Verified: zero matches across all six skills.
SKILL.md files reference a few helper scripts that live one
level above the skills folder
(run-report.js, skill-update.js,
install-id.js). They are not packaged in any skill zip and
only exist if you separately installed the suite tooling; every call to
them is guarded so a standalone install skips them silently. Two touch
the network, so they are documented in full below rather than hidden.
| Skill (version) | What it is | Files it writes | Commands it runs locally (you approve each) | Network it starts |
|---|---|---|---|---|
| godmode-lite (free, 2.3.1) | Markdown + runner/ Node CLI |
The project files you ask it to build; a consent record at <project>/.evo/godmode-lite/scoring.json; local run state under the skill dir |
node runner/... (discover, start, check, test, polish, end), git, and your own build/test commands |
Only the consent-gated outcome ping (below). Off by default. |
| blog-post-GM (free, 1.3.1) | Markdown + templates only (no scripts) | The blog HTML file it generates in your project | None of its own | None initiated by the skill. The HTML it produces contains an analytics tag and font links that load in your site visitors' browsers when you publish the page; you control whether to keep them before publishing. |
| godmode (paid, 2.3.2) | Markdown + runner/ + phases |
Project files; an optional .godmode-receipt.json in the project; a consent record under .evo/godmode/ |
node runner/..., git, build/test, optional local receipt script |
Only the consent-gated outcome ping (below). Off by default. |
| godmode-plus (paid, 2.7.1) | Markdown + runner/ + phases |
Same shape as godmode, plus the receipt |
Same shape as godmode |
Only the consent-gated outcome ping (below). Off by default. |
| godmode-evolution (paid, 3.3.1) | Markdown + runner/ (scoring, mutation, benchmark engines) + phase docs |
.evo/<skill>/ scoring, a local feedback.jsonl and outcomes-queue.jsonl; project files; benchmark working dirs |
node runner/... (score, verdict, loop, revert), git, and any gate/benchmark commands you configure (run via a shell) |
(a) A status-code health probe to a URL you put in your own benchmark/gate config (goes to your target, not to us); (b) the consent-gated outcome ping (below), off by default. |
| one-shot-scripts (paid, 3.13.0) | Markdown + runner/ gates + phase docs |
runs/ state and a local feedback.jsonl under the skill dir; project files; a consent record under .evo/one-shot-scripts/ |
node runner/... (start, discover, verify, score, end), git, your gate/benchmark commands (run via a shell), and for visual audits a headless browser against your own localhost |
(a) The same user-directed health probe as evolution; (b) the consent-gated outcome ping (below), off by default. |
The whole local execution surface is node, git,
your configured build and test commands, and, for one-shot visual audits,
a headless browser pointed at your own app on localhost. Gate
and benchmark commands run through a shell because you supply
them, so they are whatever you wrote. None of it contacts us.
godmode-mcp) sends
The godmode-mcp client is a stdio MCP server. It talks to
exactly two hosts: one Supabase Edge Function (to list the catalogue,
check entitlements, and authorize a download) and
getgodmode.dev (to fetch the zip bytes). It logs only to
stderr, and only ever prints whether a token is present or absent, never
the token itself. The one API endpoint is
https://tngklkesmvqissfrbzhn.supabase.co/functions/v1/mcp-actions,
and every request body is built as { action, ...args }. The
Supabase anon key it carries is public by design (it is the
anonymous-tier key, not a secret).
| Tool | Network | Exact request body | Auth header |
|---|---|---|---|
godmode_list_products |
POST to the API | {action:"catalog"} |
anon key |
godmode_get_product |
POST to the API | {action:"product", slug} |
anon key |
godmode_open_pricing |
No network at all | n/a (returns a pricing URL as text; does not even open a browser) | none |
godmode_install_lite |
POST to the API, then download from getgodmode.dev |
{action:"entitle", product_slug:"godmode-lite"} |
anon key |
godmode_install_skill |
POST to the API, then download from getgodmode.dev |
{action:"entitle", product_slug:slug} |
your token if GODMODE_MCP_TOKEN is set, otherwise the anon key |
godmode_list_owned_skills |
POST to the API | {action:"whoami"} |
your token (required) |
Does any local file content leave the machine through the MCP? No. The bodies above are the complete set: an action name, a product slug, or your auth token. No file is read for transmission. The install pipeline only reads and writes locally after the server returns a download URL, and the only thing it sends back is the slug.
Token handling. The client reads
GODMODE_MCP_TOKEN once at startup and then deletes it from
the environment, so child processes cannot inherit it. On authed requests
it is sent only as Authorization: Bearer <token> to the
one Supabase endpoint, and nowhere else; the download request carries no
token at all.
Never transmitted by the skills or the MCP:
The consent-gated outcome ping (off by default). Four
skills can send an anonymous outcome record to
godmode-reviews-api.onrender.com/api/outcomes
only after you opt in. The skill reads an
outcomes_api_consent flag from
.evo/<skill>/scoring.json; if it is absent, you are
asked once, explicitly. If you decline or never opt in, nothing is sent.
The default state is no consent, so the default behavior is no
transmission. When (and only when) you opt in, the record contains the
verdict, a task category, quality scores and token totals where the skill
computes them, an anonymous install ID, and any free-text note you chose
to add. It never contains your code, your files, or your paths. (The
script-based runner additionally strips emails, URLs, and paths from your
note and truncates it; the lightest skill assembles a smaller record with
no scores or token totals.)
The two identifiers that can leave the machine:
gm-
followed by 12 random bytes), generated locally and stored at
~/.claude/.install-id. It contains zero machine or user
information. It is sent with the consent-gated outcome ping above.
~/.claude/scripts/skill-update.js
(and never by a shipped skill zip or by the MCP). It is a one-way
SHA-256 hash of hostname|platform|arch|username, truncated
to 32 hex characters. It is not reversible to your hostname or
username, but it is machine-derived, so we name it here rather than
imply nothing machine-linked ever leaves. It ties an anonymous install
to update-eligibility and plan tier when you run
skill-update.js (its check is throttled to
once per 24 hours). The consent-gated outcome ping does not send it: it
uses the random ID only.
This is the complete set. If a security reviewer unpacks a tarball, reads
a SKILL.md, and follows the ~/.claude/scripts/
references, the fingerprint in skill-update.js is the one
thing they will find that we have not already named here. It is named on
purpose.
We would rather you check than trust us.
The Godmode Lite zip is downloadable at /downloads/godmode-lite.zip. Unzip it and read every file before you trust it; this is the same format every paid skill ships in.
The MCP verifies a download against the catalogue-pinned hash before extracting, and rejects a mismatch. The hashes:
| Skill | Version | Files | SHA-256 |
|---|---|---|---|
| godmode-lite (free) | 2.3.1 | 20 | 6ba7dbf8c25506d9b0e4087e825efb6e2a3eaa488b850c3136f62e4fa930eb35 |
| blog-post-GM (free) | 1.3.1 | 5 | bac219433882a4b167834fa0c4a572b8b847506d7932fbdc4f9acede3b011e35 |
| godmode (paid) | 2.3.2 | 23 | 7dfef0d319781b6c159d5264b7585de27550676ce5c0d6abd2d46cc4e0343aaf |
| godmode-plus (paid) | 2.7.1 | 23 | 307cbc8b172a6746258d6bc0ea6121ac89d079c22554c2635f06b60c9b47878f |
| godmode-evolution (paid) | 3.3.1 | 42 | 908f131313180523f057405f10157e5901b80be9e81b585a6106457622c75e3d |
| one-shot-scripts (paid) | 3.13.0 | 45 | a8ffdcf7b5c5379d11e0b087046fb9e3473e8e14e71baac30e091b87d2d85a0f |
The free zips are downloadable now. Verify either:
curl -L -o godmode-lite.zip https://getgodmode.dev/downloads/godmode-lite.zip
sha256sum godmode-lite.zip # compare to the table above
unzip -l godmode-lite.zip # read every file before you trust itThe paid zips are delivered through the entitlement flow rather than served statically, and the MCP verifies their bytes against these same pinned hashes before extracting.
npm pack godmode-mcp # or: npm view godmode-mcp
Read the client under node_modules/godmode-mcp/build/. It is
the package godmode-mcp (latest on npm is 0.1.0), MIT
licensed and published public. The build/ directory is
compiled from TypeScript but not minified or obfuscated, so it is
readable JavaScript you can audit before you grant it any trust.
The packager works from an allowlist, not a denylist. It
walks only a skill's own folder and ships only SKILL.md,
root LICENSE and protocol .md files, and the
phases/ runner/ scripts/ templates/ test/ subtrees. It
excludes node_modules, .git, run state, and
local logs. Because it never leaves the skill folder, the suite scripts at
~/.claude/scripts/ (including the fingerprint sender
skill-update.js) cannot be packaged into any zip, free or
paid. The on-disk godmode-lite.zip proves it: 20 files, all
runner/ + SKILL.md + LICENSE, and
none of the suite scripts.
Even on the trusted download, the MCP install path defends itself:
getgodmode.dev, www.getgodmode.dev, plus the API host), and redirect: 'error' so a download cannot be bounced to another host..part file, verify, extract, back up any existing skill to a timestamped .bak, then rename into place.If you find a security issue in a Godmode skill, the MCP package, or this site, email support@getgodmode.dev. We will acknowledge and respond. Please do not post exploit details publicly before we have had a chance to fix them.
See the Privacy Policy for how we handle data you give us (purchases, reviews, abuse logging) and the Terms for the license and refund policy.