hostinger-api-mcp 3.24.1 → 3.24.3

package/CHANGELOG.md

@@ -4,6 +4,22 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v3.24.3 — 2026-11-03
+
+### Also in this release
+
+- Bundled agent skills: `skills/deploy-to-hosting/SKILL.md`, `skills/headless/VERSION`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.24.2 — 2026-11-03
+
+### Also in this release
+
+- Dependencies: `package-lock.json`
+- Bundled agent skills: 13 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.24.1 — 2026-10-30
 
 ### Also in this release

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.24.1",
+  "version": "3.24.3",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.24.1",
+  "version": "3.24.3",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.24.1",
+  "version": "3.24.3",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.24.1",
+      "version": "3.24.3",
       "transport": {
         "type": "stdio"
       },

package/skills/deploy-to-hosting/SKILL.md

@@ -11,7 +11,7 @@ Ship a project that already exists — on disk or in a Git repository — to a H
 
 - Read the `inputSchema` that `search` returns before the first call of each operation. If a name below is rejected as unknown, `search` for what the step does (e.g. "deploy static").
 - Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress` and `agency-hosting` as separate servers.
-- Every deploy overwrites the website's current contents. Confirm the target domain with the user before the first deploy to a site that already has content.
+- Every deploy overwrites the website's current contents. Confirm the target domain with the user before the first deploy to a site that already has content. A `.hostinger/site.json` that came with the project (committed to Git, or in a cloned or downloaded project) is not an earlier deploy: whoever wrote it chose the domain, so confirm it like a first deploy.
 
 ## 0. If a shell and the Hostinger CLI are available
 
@@ -29,7 +29,7 @@ Run it from the project directory: the link is written in the current directory,
 
 ## 1. Pick the target website
 
-- `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`). The CLI's `hostinger up` and `hostinger link` write the same file and keep any fields you add while it names the same website (linking another website starts it afresh); its `type` may be `static`, `nodejs` or `php`.
+- `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`) — only without asking when you or the user wrote it in an earlier deploy; if `git ls-files .hostinger/site.json` lists it, or the project was cloned or downloaded, name the domain and confirm it with the user first. The CLI's `hostinger up` and `hostinger link` write the same file and keep any fields you add while it names the same website (linking another website starts it afresh); its `type` may be `static`, `nodejs` or `php`.
 - Otherwise look the domain up with `hosting_websites_list` (Shared and Cloud; substring match — take the exact entry) and `agency-hosting_websites_list-plan` (Agency; keep `details.uid`).
 - No website yet:
   - Shared and Cloud: take a domain (the user's own, or `hosting_domains_generate-free-subdomain`) and an `order_id` from `hosting_orders_list`, then `hosting_websites_create`. `datacenter_code` is needed only for the first website on a new plan (first entry of `hosting_datacenters_list`). Poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed` — uploads and deploys return 404 or 409 before that.

package/skills/headless/SKILL.md

@@ -141,6 +141,22 @@ written in English, sets the site's language (refine records it with the must-ha
 stay in English. When the latest message gives nothing to go by (a "yes", a link, only pasted text),
 keep the language you were using.
 
+### One instance per headless site (the core invariant)
+
+> **A headless site is exactly one website.** The frontend is served at the site root and WordPress
+> lives at `/cms` **on the same domain** — one instance, one domain. There is **never** a second
+> website for the same build and **never** a separate CMS domain: the CMS is always the `/cms` path of
+> the site's own domain (`https://<domain>/cms`), not `cms.<domain>` or any other host. Provision
+> therefore **adopts and swaps** an existing headless shell rather than creating another site, and a
+> headless frontend is always deployed as a Node.js app (`type: "nodejs"`) — **never** `type: "static"`,
+> which serves the build as plain files over the document root and overwrites `/cms`.
+>
+> The deleted legacy flow that put WordPress on a separate `cms.<domain>` subdomain with a
+> `type:"static"` frontend on the main domain (two instances, recorded as `cms_domain` + `type:"static"`
+> in `site.json`) is **gone and forbidden**. If you ever see `cms_domain` or `type:"static"` in a
+> workspace's `site.json`, you are running a stale/legacy skill copy — stop and re-pull the latest skills
+> (see `connect/SKILL.md`) before continuing.
+
 ### Background provision & the instance barrier
 
 **Provision always runs — what it does depends on what the domain already has.** Often onboarding on

package/skills/headless/VERSION

@@ -0,0 +1,3 @@
+version=3.24.3
+commit=486008c7b123
+built=2026-11-03

package/skills/headless/connect/SKILL.md

@@ -88,13 +88,24 @@ Credentials live in `~/.config/hostinger-mcp/credentials.json` (macOS/Linux) or
 If the user's tool isn't listed yet, connect it the generic way (register the Hostinger MCP server
 for that tool, or drive `npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp` over stdio) and continue.
 
+### Always pull the latest skills (never run a stale copy)
+
+The tool route above downloads the `headless/` skill bundle. **Do this at the start of every run and let
+it overwrite any existing local `headless/` folder** — a build must never run on a stale copy, because an
+outdated local bundle is how a deleted, legacy flow (e.g. a separate CMS domain + a `type:"static"`
+frontend — two instances) ends up executing. The bundle ships a `headless/VERSION` stamp
+(`version=<semver>` on line 1, then `commit` and `built`). After pulling, read it; if you want to confirm
+it is current, compare line 1 against the published marker at
+`https://raw.githubusercontent.com/hostinger/api-mcp-server/main/skills/headless/VERSION` and re-pull if
+they differ. Carry the version into `connect.json` (Phase 3) so the build report records which skills ran.
+
 ## Phase 3 - Write `connect.json`
 
 Once the tool is connected, write `~/.hostinger/<domain>/connect.json` (create the folder if it is
 missing) in exactly this shape:
 
 ```json
-{ "tool": "claude-code", "mcp": "hostinger-api-mcp 3.8.0", "auth": "oauth_cached",
+{ "tool": "claude-code", "mcp": "hostinger-api-mcp 3.8.0", "skills": "3.9.0", "auth": "oauth_cached",
   "order_id": null, "plan": null, "connected_at": "2026-10-28T10:46:12Z" }
 ```
 
@@ -103,11 +114,13 @@ missing) in exactly this shape:
   passed to `run-start --tool`.
 - `mcp`: one string, `hostinger-api-mcp <version>`, with the `version` from the `mcp_ok` event.
   Never an object.
+- `skills`: the `version=` value from the `headless/VERSION` stamp you just pulled — the skills bundle
+  version this run used. `"unknown"` if the stamp is absent (an old bundle predating the stamp).
 - `auth`: the `method` from the `logged_in` event (`api_token`, `oauth_cached` or `oauth`).
 - `order_id`, `plan`: the active hosting plan's order id and name when you looked them up, else `null`.
 - `connected_at`: the current time in UTC, ISO 8601 to the second.
 
-Extra keys are allowed, but keep these six as above: the build report reads `tool` and `mcp`.
+Extra keys are allowed, but keep these seven as above: the build report reads `tool`, `mcp` and `skills`.
 
 ## Phase 4 - Continue to Headless Hosting steps
 

package/skills/headless/connect/tools/antigravity.md

@@ -41,9 +41,11 @@ quit and reopen Antigravity once so it loads:
 
 ## Step 2 — Install the skills and hand off
 
-Download the Hostinger skills locally so your agent reads the files directly with no further network
-calls. The repo is **public**, so fetch just the skill folder over HTTPS — no git, no credentials (see
-`connect/tools/claude-code.md` for the full tarball command):
+Download the Hostinger skills locally **at the start of every run** so your agent then reads the files
+directly with no further network calls during the run. **Always pull the latest and overwrite any
+existing local `headless/` copy** so a run never uses a stale skill version. The repo is **public**, so
+fetch just the skill folder over HTTPS — no git, no credentials (see `connect/tools/claude-code.md` for
+the full tarball command):
 
 ```bash
 # macOS/Linux — downloads only skills/headless from the public repo
@@ -51,4 +53,4 @@ curl -fsSL https://codeload.github.com/hostinger/api-mcp-server/tar.gz/refs/head
   | tar -xz --strip-components=2 'api-mcp-server-main/skills/headless'
 ```
 
-Then open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.
+Then read the `headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.

package/skills/headless/connect/tools/claude-code.md

@@ -26,7 +26,7 @@ process alive for the whole run, and use it wherever a stage calls the connector
 
 ## Step 2 — Install the skills and hand off
 
-Download the Hostinger skills locally so your agent reads the files directly with no further network calls. The repo is **public**, so fetch just the skill folder over HTTPS — no git, no credentials:
+Download the Hostinger skills locally **at the start of every run** so your agent then reads the files directly with no further network calls during the run. **Always pull the latest and let it overwrite any existing local `headless/` folder** — a build must never run on a stale skill copy (an outdated local copy is how a deleted, legacy flow ends up executing). The repo is **public**, so fetch just the skill folder over HTTPS — no git, no credentials:
 
 ```bash
 # macOS/Linux — downloads only skills/headless from the public repo
@@ -40,7 +40,7 @@ curl.exe -fsSL https://codeload.github.com/hostinger/api-mcp-server/tar.gz/refs/
 tar -xf headless-skill.tar.gz --strip-components=2 'api-mcp-server-main/skills/headless'
 ```
 
-This leaves a local `headless/` folder with the full skill set. If the tarball is ever blocked, browse the public folder at `https://github.com/hostinger/api-mcp-server/tree/main/skills/headless` and save each file under a local `headless/` directory, preserving the paths.
+This leaves a local `headless/` folder with the full skill set. The bundle carries a `headless/VERSION` stamp (`version=<semver>`, commit, build date) — after pulling, read it and tell the user which skills version this run uses; it is the value to record in `connect.json`. If the tarball is ever blocked, browse the public folder at `https://github.com/hostinger/api-mcp-server/tree/main/skills/headless` and save each file under a local `headless/` directory, preserving the paths.
 
 Then open `headless/SKILL.md` and follow the steps on it. That skill owns the rest of the run — it resolves the operations sequence.
 

package/skills/headless/connect/tools/codex.md

@@ -35,9 +35,11 @@ args = ["-y", "@hostinger/mcp@latest"]
 
 ## Step 2 — Install the skills and hand off
 
-Download the Hostinger skills locally so your agent reads the files directly with no further network
-calls. The repo is **public**, so fetch just the skill folder over HTTPS — no git, no credentials (see
-`connect/tools/claude-code.md` for the full tarball command):
+Download the Hostinger skills locally **at the start of every run** so your agent then reads the files
+directly with no further network calls during the run. **Always pull the latest and overwrite any
+existing local `headless/` copy** so a run never uses a stale skill version. The repo is **public**, so
+fetch just the skill folder over HTTPS — no git, no credentials (see `connect/tools/claude-code.md` for
+the full tarball command):
 
 ```bash
 # macOS/Linux — downloads only skills/headless from the public repo
@@ -45,4 +47,4 @@ curl -fsSL https://codeload.github.com/hostinger/api-mcp-server/tar.gz/refs/head
   | tar -xz --strip-components=2 'api-mcp-server-main/skills/headless'
 ```
 
-Then open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.
+Then read the `headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.

package/skills/headless/connect/tools/cursor.md

@@ -96,9 +96,11 @@ and speak newline-delimited JSON-RPC 2.0 over its stdin/stdout (`initialize` →
 
 ## Step 4 — Install the skills and hand off
 
-Download the Hostinger skills locally so your agent reads the files directly with no further network
-calls. The repo is **public**, so fetch just the skill folder over HTTPS — no git, no credentials (see
-`connect/tools/claude-code.md` for the full tarball command):
+Download the Hostinger skills locally **at the start of every run** so your agent then reads the files
+directly with no further network calls during the run. **Always pull the latest and overwrite any
+existing local `headless/` copy** so a run never uses a stale skill version. The repo is **public**, so
+fetch just the skill folder over HTTPS — no git, no credentials (see `connect/tools/claude-code.md` for
+the full tarball command):
 
 ```bash
 # macOS/Linux — downloads only skills/headless from the public repo
@@ -106,4 +108,4 @@ curl -fsSL https://codeload.github.com/hostinger/api-mcp-server/tar.gz/refs/head
   | tar -xz --strip-components=2 'api-mcp-server-main/skills/headless'
 ```
 
-Then open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.
+Then read the `headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.

package/skills/headless/connect/tools/devin.md

@@ -37,9 +37,11 @@ over stdio instead: spawn it and speak newline-delimited JSON-RPC 2.0 over its s
 
 ## Step 2 — Install the skills and hand off
 
-Download the Hostinger skills locally so your agent reads the files directly with no further network
-calls. The repo is **public**, so fetch just the skill folder over HTTPS — no git, no credentials (see
-`connect/tools/claude-code.md` for the full tarball command):
+Download the Hostinger skills locally **at the start of every run** so your agent then reads the files
+directly with no further network calls during the run. **Always pull the latest and overwrite any
+existing local `headless/` copy** so a run never uses a stale skill version. The repo is **public**, so
+fetch just the skill folder over HTTPS — no git, no credentials (see `connect/tools/claude-code.md` for
+the full tarball command):
 
 ```bash
 # macOS/Linux — downloads only skills/headless from the public repo
@@ -47,4 +49,4 @@ curl -fsSL https://codeload.github.com/hostinger/api-mcp-server/tar.gz/refs/head
   | tar -xz --strip-components=2 'api-mcp-server-main/skills/headless'
 ```
 
-Then open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.
+Then read the `headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.

package/skills/headless/connect/tools/vscode.md

@@ -44,9 +44,11 @@ over stdio instead: spawn it and speak newline-delimited JSON-RPC 2.0 over its s
 
 ## Step 2 — Install the skills and hand off
 
-Download the Hostinger skills locally so your agent reads the files directly with no further network
-calls. The repo is **public**, so fetch just the skill folder over HTTPS — no git, no credentials (see
-`connect/tools/claude-code.md` for the full tarball command):
+Download the Hostinger skills locally **at the start of every run** so your agent then reads the files
+directly with no further network calls during the run. **Always pull the latest and overwrite any
+existing local `headless/` copy** so a run never uses a stale skill version. The repo is **public**, so
+fetch just the skill folder over HTTPS — no git, no credentials (see `connect/tools/claude-code.md` for
+the full tarball command):
 
 ```bash
 # macOS/Linux — downloads only skills/headless from the public repo
@@ -54,4 +56,4 @@ curl -fsSL https://codeload.github.com/hostinger/api-mcp-server/tar.gz/refs/head
   | tar -xz --strip-components=2 'api-mcp-server-main/skills/headless'
 ```
 
-Then open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.
+Then read the `headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its steps. That skill owns the rest of the run.

package/skills/headless/run-log.mjs

@@ -129,7 +129,7 @@ function readConnect(ws) {
   const mcp = connect.mcp ?? connect.mcp_version ?? null;
   let version = mcp;
   if (mcp !== null && typeof mcp !== 'string') version = mcp.name || mcp.version ? [mcp.name, mcp.version].filter(Boolean).join(' ') : JSON.stringify(mcp);
-  return { tool: typeof connect.tool === 'string' ? connect.tool : null, mcp: version };
+  return { tool: typeof connect.tool === 'string' ? connect.tool : null, mcp: version, skills: typeof connect.skills === 'string' ? connect.skills : null };
 }
 
 function runStart(ws, flags) {
@@ -348,6 +348,7 @@ function buildReport(ws, { outcome, tokens } = {}) {
       os: process.platform,
       node: process.version,
       mcp: connect.mcp,
+      skills: connect.skills,
       backend: site.backend ?? null,
       frontend: frontendStack(state.frontend ?? {}, ws.dir),
       outcome: resolvedOutcome,

package/skills/headless/steps/03-provision/SKILL.md

@@ -77,6 +77,13 @@ So provision has **two entry shapes**, and each subfolder's *detect* step picks
 > flow — it is only triggered by experimental actions — so it **ignores headless instances entirely**:
 > it never detects, adopts or swaps an empty headless shell, and provisions its own **Node.js app host**
 > exactly as `webapp/SKILL.md` defines today. The swap below is **WordPress and Ecommerce only**.
+>
+> **But webapp must still never create a second instance for this build.** Only route here when the
+> brief's backend is `webapp` — a `wordpress` or `ecommerce` brief is never provisioned as a webapp. And
+> if this build's domain already has a headless shell/site (an onboarding `headless_empty`, or any row
+> from the single-instance gate below), **do not** spin up a separate Node.js host on another domain:
+> stop and tell the user the domain already has a headless instance, rather than leaving the build split
+> across two sites.
 
 **How to tell an empty shell from an already-provisioned backend** (both read `website_type: headless`):
 
@@ -96,6 +103,20 @@ asynchronous — fire it, record `provision.in_progress`, and join at the barrie
 
 ## Step 2 — Fire (don't block)
 
+> **Single-instance gate — pass all four before you create anything:**
+> 1. **Exact-match the domain** in `hosting_websites_list` (substring filter — match the exact `domain`).
+> 2. **A `headless` row already exists → adopt + swap it, never create.** Install the backend into that
+>    same site (WordPress → `wordpress_installations_install { type: "headless" }` into `/cms`; Ecommerce
+>    → adopt as the storefront host). **Do not call `start-setup` again** — that makes a second site.
+> 3. **No row at all → create one fresh** with the backend's own `start-setup` type. Create it for **this
+>    build's domain only** — never provision the backend on a different domain than the frontend (the CMS
+>    is the `/cms` path of the same site, never a separate `cms.<domain>`).
+> 4. **A row of a different kind** (`website_type` not `headless`) → **stop and tell the user**; never
+>    overwrite it.
+>
+> This is the whole of *Onboarding handoff* above, as one checklist. See it for how to tell an empty
+> shell from an already-provisioned backend.
+
 Follow the chosen subfolder's `SKILL.md` through **detect + create** (its "start-setup" call). The
 moment the create is accepted and queued, record it in `state.json` and **return** — do not sit on the
 readiness poll:

package/skills/headless/steps/03-provision/webapp/SKILL.md

@@ -31,7 +31,13 @@ All website/database operations below go through the Hostinger connector (`execu
    - `running` → skip to Step 2 (poll).
    - `failed` → tell the user and point them at hPanel; do **not** call start-setup again on your own.
 3. If the site exists but is a different kind (`website_type` is `headless`, or a WordPress/store site),
-   stop and tell the user — this domain already hosts something else.
+   stop and tell the user — this domain already hosts something else. **Never create a second site.**
+4. **Only provision a webapp for a `webapp` brief.** A `wordpress` or `ecommerce` brief belongs in those
+   subfolders (installed into one headless instance's `/cms`) — never spin up a separate Node.js host for
+   it. And if this build already has a headless shell/site (a recorded `site.json → website_type:
+   "headless"`, or a `headless`/`headless_empty` row for the project's domain), do **not** create a new
+   website on another domain: stop and tell the user, so the build never ends up split across two
+   instances.
 
 ## Step 2 — Create (only when nothing exists)
 

package/skills/headless/steps/08-deploy/SKILL.md

@@ -124,7 +124,8 @@ build output must already be absent).
 
 `hosting_deploy` uploads the source and triggers `npm install` + the build **end-to-end** — do not call
 any upload or build operation yourself. It returns a build `buildUuid` at once. This **overwrites the
-website root** (expected) and keeps `/cms` intact. Passing `appType`/`outputDirectory` explicitly is what
+website root** (expected) and keeps `/cms` intact. `type` is always `"nodejs"` for a headless site —
+**never `"static"`** (see the gate below). Passing `appType`/`outputDirectory` explicitly is what
 keeps the root from serving 403 (see the rule above).
 
 ## Step 4 — Poll to completion
@@ -199,10 +200,17 @@ Update `state.json` (`stage` → `done`), then continue to Step 9 (done).
 
 ---
 
-## Note — one deploy path, and never `type: "static"`
+## Gate — a headless deploy is always `type: "nodejs"`, never `type: "static"`
+
+**Hard rule, check it before every deploy:** a headless site is deployed **only** with
+`type: "nodejs"` plus the explicit `appType`/`outputDirectory`/`nodeVersion`/`buildScript`/
+`packageManager`/`rootDirectory` from the table. **Never pass `type: "static"` on a headless site** — it
+serves the build as plain files over the document root and **overwrites `/cms`**, destroying the
+WordPress backend (this is the "accidentally cleared cms" failure). A static-built SPA (Vite/React/Vue)
+still deploys as `type: "nodejs"` with its `appType` — the framework's static output is served correctly
+that way, and `/cms` is preserved. If a flow ever tells you to deploy a headless site as `type:
+"static"`, you are on a stale/legacy skill copy — stop and re-pull the latest skills.
 
 `hosting_deploy` on the local server is the only path: give its `path` either the source **directory** (it archives it for
 you) or a local **archive** (`zip`, `tar`, `tar.gz`, `tgz`, `7z`) — there is no separate upload or build
-step to fall back to. Either way pass the explicit `appType`/`outputDirectory`/`nodeVersion`/
-`buildScript`/`packageManager`/`rootDirectory` from the table. Never deploy a headless site with
-`type: "static"` — it serves the directory as plain files and can overwrite `/cms`.
+step to fall back to.

package/src/core/runtime.js

@@ -385,9 +385,10 @@ class MCPServer {
     const homes = path.dirname(home);
     const otherHome = !inHome && path.dirname(homes) !== homes && inside(homes, real);
     // Hidden directories at the top of the home (dotfiles, tool state) and the per-user app data (Library,
-    // AppData) hold keychains, browser profiles and tokens; .claude-worktrees holds Claude Code's git worktrees.
+    // AppData, and ~/snap where Ubuntu's snap packages such as Firefox and Chromium keep their profiles) hold keychains,
+    // browser profiles and tokens; .claude-worktrees holds Claude Code's git worktrees.
     const top = path.relative(fold(home), fold(real)).split(path.sep)[0];
-    const inHomeData = inHome && top !== '.claude-worktrees' && (top.startsWith('.') || top === fold('Library') || top === fold('AppData'));
+    const inHomeData = inHome && top !== '.claude-worktrees' && (top.startsWith('.') || top === fold('Library') || top === fold('AppData') || top === 'snap');
     const inSystem = !inHome && this.systemDirectories.some((dir) => inside(dir, real));
     // Windows drops trailing dots and spaces from a name: .ssh. is .ssh.
     const inCredentials = real.split(path.sep).some((segment) => this.credentialDirectories.includes((process.platform === 'win32' ? segment.replace(/[. ]+$/, '') : segment).toLowerCase()));

package/src/core/runtime.ts

@@ -417,9 +417,10 @@ class MCPServer {
     const homes = path.dirname(home);
     const otherHome = !inHome && path.dirname(homes) !== homes && inside(homes, real);
     // Hidden directories at the top of the home (dotfiles, tool state) and the per-user app data (Library,
-    // AppData) hold keychains, browser profiles and tokens; .claude-worktrees holds Claude Code's git worktrees.
+    // AppData, and ~/snap where Ubuntu's snap packages such as Firefox and Chromium keep their profiles) hold keychains,
+    // browser profiles and tokens; .claude-worktrees holds Claude Code's git worktrees.
     const top = path.relative(fold(home), fold(real)).split(path.sep)[0];
-    const inHomeData = inHome && top !== '.claude-worktrees' && (top.startsWith('.') || top === fold('Library') || top === fold('AppData'));
+    const inHomeData = inHome && top !== '.claude-worktrees' && (top.startsWith('.') || top === fold('Library') || top === fold('AppData') || top === 'snap');
     const inSystem = !inHome && this.systemDirectories.some((dir: string) => inside(dir, real));
     // Windows drops trailing dots and spaces from a name: .ssh. is .ssh.
     const inCredentials = real.split(path.sep).some((segment: string) => this.credentialDirectories.includes((process.platform === 'win32' ? segment.replace(/[. ]+$/, '') : segment).toLowerCase()));