hostinger-api-mcp 3.30.1 → 3.30.2

package/CHANGELOG.md

@@ -4,6 +4,17 @@ 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.30.2 — 2026-11-06
+
+### Also in this release
+
+- Documentation: `README.md`
+- Distribution manifests: `gemini-extension.json`
+- Bundled agent skills: 18 files
+- OAuth sign-in flow: `src/core/oauth.js`, `src/core/oauth.ts`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.30.1 — 2026-11-05
 
 ### Also in this release

package/README.md

@@ -133,11 +133,14 @@ hostinger-api-mcp --logout
 
 ### JSON configuration for Claude, Cursor, etc.
 
+Register Node and the server script by absolute path, never `npx` or a bare `node`/`hostinger-api-mcp`: tools start the server in your project, where `npx` puts the project's `node_modules/.bin` first on `PATH`, a version manager (asdf, mise) runs whatever Node the project's `.tool-versions` names, and Windows looks a bare name up in the project folder first. Any of these lets a cloned repository run its own code with your Hostinger credentials. After the global install, `node -p process.execPath` prints the Node path and `npm root -g` the folder that holds `@hostinger/mcp`. Run both from your home folder.
+
 ```json
 {
     "mcpServers": {
         "hostinger-api": {
-            "command": "hostinger-api-mcp",
+            "command": "/absolute/path/to/node",
+            "args": ["/absolute/path/to/global/node_modules/@hostinger/mcp/src/servers/all.js"],
             "env": {
                 "DEBUG": "false",
                 "HOSTINGER_API_TOKEN": "YOUR API TOKEN"

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.30.1",
+  "version": "3.30.2",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {
@@ -9,6 +9,7 @@
         "-y",
         "@hostinger/mcp"
       ],
+      "cwd": "${extensionPath}",
       "env": {
         "HOSTINGER_API_TOKEN": "${HOSTINGER_API_TOKEN}"
       }

package/package.json

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

package/server.json

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

package/skills/headless/SKILL.md

@@ -192,13 +192,15 @@ has usually outlasted the job, so it returns at once. The single rule that makes
 ### Waiting on Hostinger: `wait.mjs`
 
 `wait.mjs` (next to this file) waits for a slow Hostinger job in one command, so you don't spend a turn
-on every check:
+on every check. Run it, like `push-content.mjs`, from the home folder (`cd "$HOME" && …`): both
+start the Hostinger MCP server with the user's sign-in, and a version manager's `node` (asdf, mise)
+runs whatever Node the current project's `.tool-versions` names:
 
 ```bash
-node <skill>/wait.mjs setup <domain>              # a fresh site's setup → completed
-node <skill>/wait.mjs cms <domain> <username>     # a shell swap's WordPress install at /cms → valid
-node <skill>/wait.mjs build <domain> <buildUuid>  # the deploy build → completed, then the root serves 200
-node <skill>/wait.mjs live <domain>               # the root serves 200
+cd "$HOME" && node <skill>/wait.mjs setup <domain>              # a fresh site's setup → completed
+cd "$HOME" && node <skill>/wait.mjs cms <domain> <username>     # a shell swap's WordPress install at /cms → valid
+cd "$HOME" && node <skill>/wait.mjs build <domain> <buildUuid>  # the deploy build → completed, then the root serves 200
+cd "$HOME" && node <skill>/wait.mjs live <domain>               # the root serves 200
 ```
 
 Run it in the foreground, with a `--timeout` just under your tool's command limit (e.g. `--timeout 9m`

package/skills/headless/VERSION

@@ -1,3 +1,3 @@
-version=3.30.1
-commit=4d02050e3406
-built=2026-11-05
+version=3.30.2
+commit=27fa03d3cce1
+built=2026-11-06

package/skills/headless/connect/SKILL.md

@@ -77,10 +77,10 @@ Read `<skill>/VERSION`: its line 1 is the skills version this run uses, which go
 Run the bundled script. It verifies the MCP server and handles sign-in, emitting one JSON event per line on stdout. Run it as a background/streaming process. Show the user only the sign-in URL (`awaiting_user`) or a
 failure's `detail`, and handle the other events silently (table below).
 
-The script is safe and inspectable: it only checks the MCP server via `npx` and drives the OAuth sign-in (a browser flow with a localhost callback) — no other network calls, no filesystem writes.
+The script is safe and inspectable: it copies the launcher to `~/.hostinger/mcp/launch.mjs`, checks the MCP server through it and drives the OAuth sign-in (a browser flow with a localhost callback) — no other network calls, no other filesystem writes.
 
 ```bash
-node <skill>/connect/bootstrap.mjs
+cd "$HOME" && node <skill>/connect/bootstrap.mjs
 ```
 
 ### Relay these events
@@ -89,11 +89,12 @@ The script emits one JSON object per line:
 
 | Event | What to do                                                                                                                                                                                                                           |
 | --- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `launcher` (`command`, `args`) | How to start the MCP server: use these for every registration (Phase 2). |
 | `mcp_ok` | MCP server reachable — continue.                                                                                                                                                                                                     |
 | `logged_in` | Already authenticated (env token or a previous sign-in) — continue.                                                                                                                                                                  |
 | `awaiting_user` (`verificationUri`) | A browser window should have opened on the user's machine. Show the URL in plain prose and wait for the user to finish signing in. The OAuth callback lands on a localhost port, so the sign-in must be completed on this same machine. |
 | `success` | Bootstrap done — continue to Phase 2. |
-| `mcp_unreachable` / `login_failed` (with `detail`) | Stop and show the user the `detail`. Do not improvise a parallel setup by hand. |
+| `launcher_failed` / `mcp_unreachable` / `login_failed` (with `detail`) | Stop and show the user the `detail`. Do not improvise a parallel setup by hand. |
 
 If the environment has a `HOSTINGER_API_TOKEN` set (for example CI), the bootstrap reports `logged_in` immediately — no browser needed.
 
@@ -107,8 +108,8 @@ hostinger-api-mcp --login
 hostinger-api-mcp --logout
 
 # Without a global install:
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --login
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --logout
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --login
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --logout
 ```
 
 Credentials live in `~/.config/hostinger-mcp/credentials.json` (macOS/Linux) or `%APPDATA%\hostinger-mcp\credentials.json` (Windows) and are shared by every Hostinger MCP binary. OAuth works only when the tool runs the server over its default local (stdio) transport, which is what every registration below uses; `--http` needs `HOSTINGER_API_TOKEN`.
@@ -127,8 +128,8 @@ one group says nothing about the other:
 
 | Group | Operations | Comes from | Needed by |
 |---|---|---|---|
-| **Hosting** | `hosting_*` (websites, deploy, build report), `wordpress_*` | `hostinger` (`npx -y --prefix="$HOME" @hostinger/mcp@latest`), or the scoped servers such as `hostinger-hosting` + `hostinger-wordpress` | every build |
-| **Ecommerce** | `ecommerce_*` (stores, products, shipping, payments) | **only** `hostinger-ecommerce` (`npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp`), or the Ecommerce MCP in the Hostinger Connector. Neither `hostinger` nor the scoped hosting servers include it | Ecommerce backends (chosen later, in refine) |
+| **Hosting** | `hosting_*` (websites, deploy, build report), `wordpress_*` | `hostinger` (`<command> <launcher>`), or the scoped servers such as `hostinger-hosting` + `hostinger-wordpress` | every build |
+| **Ecommerce** | `ecommerce_*` (stores, products, shipping, payments) | **only** `hostinger-ecommerce` (`<command> <launcher> hostinger-ecommerce-mcp`), or the Ecommerce MCP in the Hostinger Connector. Neither `hostinger` nor the scoped hosting servers include it | Ecommerce backends (chosen later, in refine) |
 
 Check each group on its own, right here at connect, before anything else:
 
@@ -148,8 +149,8 @@ Most coding tools load MCP servers only when they start, so a server registered
 until the tool restarts. When either tool group above is missing:
 
 1. **Register the missing servers** in the tool's MCP config, as the tool route below shows: `hostinger`
-   (`npx -y --prefix="$HOME" @hostinger/mcp@latest`) if the hosting group is missing, and `hostinger-ecommerce`
-   (`npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp`) if the ecommerce group is missing.
+   (`<command> <launcher>`) if the hosting group is missing, and `hostinger-ecommerce`
+   (`<command> <launcher> hostinger-ecommerce-mcp`) if the ecommerce group is missing.
    Skip a server that is already registered under its name. When neither group is there, register
    both: the backend isn't chosen until refine, and one restart then covers every backend.
 2. **Write `connect.json`** (Phase 3) before you stop. The skill folder from Phase 1 stays in place,
@@ -163,12 +164,28 @@ until the tool restarts. When either tool group above is missing:
 
 If a tool loads new servers without a restart (VS Code), use them right away and skip steps 3–4.
 
-**Every `npx` command and registration keeps `--prefix` set to the user's home folder.** The tool
-starts the server, and you run commands, in the user's project, often a cloned repository or
-template. Without `--prefix`, npm reads the `.npmrc` there, and whoever wrote it can point npx at
-another registry or run their own code. In shell commands write `--prefix="$HOME"` (the shell expands
-it when you register). In JSON or TOML configs replace `<home>` with the home folder's absolute path
-(`echo $HOME`, e.g. `/Users/me` or `C:\\Users\\me`). Never drop the flag or leave `<home>` in place.
+**Every registration and every command that starts the MCP server goes through the launcher**
+(`~/.hostinger/mcp/launch.sh` and `launch.mjs`, which the bootstrap writes): never `npx` directly, with or without
+`--prefix`. The tool starts the server, and you run commands, in the user's project, often a cloned
+repository or template. npx run there puts the project's `node_modules/.bin` first on PATH and reads
+its `.npmrc`, so whoever wrote the project runs their own `node` with the user's Hostinger sign-in.
+The launcher runs npx from the home folder instead. A registration runs exactly the bootstrap's
+`launcher` event, never a bare `node`: a version manager (asdf, mise) picks the Node that the project's
+own `.tool-versions` names. On macOS and Linux the event is `/bin/sh` with `launch.sh`, which finds
+Node only after moving to the home folder, so Node upgrades don't break it; on Windows it is the
+absolute path of `node.exe` with `launch.mjs`. Replace `<command>` and `<launcher>` with that event's
+`command` and `args[0]`, in shell commands and in JSON or TOML configs alike, and never leave a
+placeholder in place. In JSON and TOML configs, double every backslash of a Windows path
+(`C:\\Program Files\\nodejs\\node.exe`); a single one is an escape there (`\n` in `\nodejs` becomes a
+newline). Commands you run yourself start in the home folder
+(`cd "$HOME" && node …`) for the same reason.
+
+**An existing Hostinger registration is "already registered" only when it runs exactly the
+bootstrap's `launcher` event** (same `command`, `args[0]` the launcher, plus `hostinger-ecommerce-mcp`
+for that server). Before you trust one (both groups present, or a name the tool lists), check its
+command (Claude Code: `claude mcp get <name>`; otherwise the tool's MCP config). Anything else, such as
+`npx`, a bare `node` or `hostinger-api-mcp`, or any other command or path than the event's:
+remove it and register it again through the launcher, then follow *register, restart, resume*.
 
 | Tool        | Route                           |
 |-------------|---------------------------------|
@@ -180,7 +197,7 @@ it when you register). In JSON or TOML configs replace `<home>` with the home fo
 | Devin       | `connect/tools/devin.md`        |
 
 If the user's tool isn't listed yet, connect it the generic way: register both Hostinger MCP servers
-in that tool's MCP config (command `npx`, args as above), then follow *register, restart, resume*.
+in that tool's MCP config (command `<command>`, args `<launcher>` as above), then follow *register, restart, resume*.
 
 ### The skills come from Phase 1 only
 

package/skills/headless/connect/bootstrap.mjs

@@ -2,10 +2,10 @@
 // Hostinger Headless — bootstrap.
 // Verifies the Hostinger MCP server is reachable and drives the OAuth sign-in,
 // emitting one JSON event per line on stdout so a coding agent can relay
-// progress to the user. No filesystem writes besides what the MCP itself
-// stores (OAuth credentials); no network calls of its own.
+// progress to the user. Its only writes are the launcher (~/.hostinger/mcp/launch.mjs, which
+// coding tools register) and what the MCP itself stores (OAuth credentials); no network calls of its own.
 import { spawn, spawnSync } from 'node:child_process';
-import { existsSync, readFileSync } from 'node:fs';
+import { copyFileSync, existsSync, mkdirSync, readFileSync } from 'node:fs';
 import path from 'node:path';
 import os from 'node:os';
 
@@ -17,19 +17,30 @@ const fail = (event, extra = {}) => {
   process.exit(1);
 };
 
-// ── platform-safe binary names (npm/npx are .cmd on Windows) ─────────────────
+// ── the MCP server, always through the launcher ──────────────────────────────
+// launch.mjs runs the latest published package via npx from the home folder (see its header for why
+// npx must never run in the project). Coding tools register the home copy, which every run refreshes,
+// so a registration keeps working when the skill folder moves to a new version.
 const isWin = process.platform === 'win32';
-const bin = (name) => (isWin ? `${name}.cmd` : name);
-// Run the MCP via npx — no global install, always the latest published version.
-// Use --package so npx resolves the published package, then invoke the unified binary.
-const MCP = [bin('npx'), '-y', '--package=@hostinger/mcp@latest', 'hostinger-api-mcp'];
-// Node >= 18.20.2 / 20.12.2 refuses to spawn a .cmd/.bat without a shell
-// (CVE-2024-27980), so npx.cmd needs shell:true on Windows. Our args are all
-// fixed literals, so enabling the shell introduces no injection risk.
-const spawnShell = isWin;
+const LAUNCHER = path.join(os.homedir(), '.hostinger', 'mcp', 'launch.mjs');
+try {
+  mkdirSync(path.dirname(LAUNCHER), { recursive: true });
+  copyFileSync(new URL('./launch.mjs', import.meta.url), LAUNCHER);
+  copyFileSync(new URL('./launch.sh', import.meta.url), LAUNCHER.replace(/\.mjs$/, '.sh'));
+} catch (e) {
+  fail('launcher_failed', { detail: String(e) });
+}
+const MCP = [process.execPath, LAUNCHER];
+// A registration never names a bare `node`: Windows looks it up in the working directory (the project)
+// first, and a version manager's shim (asdf, mise) runs the Node the project's .tool-versions names.
+// macOS/Linux register /bin/sh with launch.sh, which finds node only after moving to home, so Node
+// upgrades keep working. Windows names this Node by absolute path (this script runs from home).
+emit('launcher', isWin
+  ? { command: process.execPath, args: [LAUNCHER] }
+  : { command: '/bin/sh', args: [LAUNCHER.replace(/\.mjs$/, '.sh')] });
 
 function capture(cmd, args) {
-  const r = spawnSync(cmd, args, { encoding: 'utf8', shell: spawnShell, cwd: os.homedir() });
+  const r = spawnSync(cmd, args, { encoding: 'utf8', cwd: os.homedir() });
   return { status: r.status ?? 1, out: `${r.stdout || ''}${r.stderr || ''}`, error: r.error };
 }
 
@@ -72,7 +83,7 @@ function existingAuth() {
 // prefix — forward it so the agent can show it if the browser didn't open.
 function login() {
   return new Promise((resolve) => {
-    const child = spawn(MCP[0], [...MCP.slice(1), '--login'], { shell: spawnShell, cwd: os.homedir() });
+    const child = spawn(MCP[0], [...MCP.slice(1), '--login'], { cwd: os.homedir() });
     let diag = '';
     let urlSent = false;
     const collect = (chunk) => {

package/skills/headless/connect/launch.mjs

@@ -0,0 +1,42 @@
+#!/usr/bin/env node
+// Hostinger Headless — starts the latest Hostinger MCP server for a coding tool or a script.
+//   node launch.mjs [hostinger-<group>-mcp] [--login | --logout | --version]
+//
+// Coding tools start stdio servers in the user's project, often a cloned repository or template.
+// npx run there puts <project>/node_modules/.bin, and the same folder of every parent, first on PATH
+// (no npm flag turns that off) and reads the project's .npmrc, so the project's own `node` would run
+// the server with the user's Hostinger credentials. This launcher runs npx from the home folder, with
+// no relative or node_modules entries left on PATH, so nothing in the project is ever looked up.
+import { spawn } from 'node:child_process';
+import { homedir } from 'node:os';
+import path from 'node:path';
+
+const [PACKAGE, DEFAULT_BIN] = ['--package=@hostinger/mcp@latest', 'hostinger-api-mcp'];
+const isWin = process.platform === 'win32';
+const home = homedir();
+
+const args = process.argv.slice(2);
+// npx.cmd needs a shell on Windows (CVE-2024-27980), so every argument must be shell-inert.
+if (args.some((a) => !/^[\w@.=:/-]+$/.test(a))) {
+  process.stderr.write(`launch.mjs: unexpected argument in ${JSON.stringify(args)}\n`);
+  process.exit(2);
+}
+const bin = /^[a-z0-9-]+-mcp$/.test(args[0] ?? '') ? args.shift() : DEFAULT_BIN;
+
+// Windows may spell it Path; a relative entry or a node_modules folder can come from the project.
+// The server returns to the project once started, so relative paths in tool arguments still work
+// (launch.sh has already moved to home and names the project itself).
+const env = { ...process.env, MCP_PROJECT_DIR: process.env.MCP_PROJECT_DIR || process.cwd() };
+for (const key of Object.keys(env).filter((k) => k.toUpperCase() === 'PATH')) {
+  env[key] = env[key].split(path.delimiter)
+    .filter((p) => path.isAbsolute(p) && !p.split(/[\\/]/).includes('node_modules'))
+    .join(path.delimiter);
+}
+
+const child = spawn(isWin ? 'npx.cmd' : 'npx', ['-y', PACKAGE, bin, ...args], { cwd: home, env, stdio: 'inherit', shell: isWin });
+for (const signal of ['SIGINT', 'SIGTERM', 'SIGHUP']) process.on(signal, () => child.kill(signal));
+child.on('error', (e) => {
+  process.stderr.write(`launch.mjs: could not start npx: ${e.message}\n`);
+  process.exit(1);
+});
+child.on('exit', (code, signal) => process.exit(code ?? (signal ? 1 : 0)));

package/skills/headless/connect/launch.sh

@@ -0,0 +1,23 @@
+#!/bin/sh
+# Hostinger Headless — what coding tools register on macOS and Linux: /bin/sh <home>/.hostinger/mcp/launch.sh
+# /bin/sh never moves, and node is looked up only here, after moving to the home folder, so a Node
+# upgrade (Homebrew, nvm, asdf) keeps the registration working, and a version manager's shim picks the
+# user's own Node, never the one a project's .tool-versions names. Relative and node_modules entries
+# are dropped from PATH first: either could hold a node the project put there.
+# The server returns to the project once started (relative paths in tool arguments), so name it first.
+MCP_PROJECT_DIR=$(pwd)
+export MCP_PROJECT_DIR
+cd || exit 1
+set -f
+safe=
+IFS=:
+for dir in $PATH; do
+  case $dir in
+    /*node_modules*) ;;
+    /*) safe=${safe:+$safe:}$dir ;;
+  esac
+done
+unset IFS
+PATH=$safe
+export PATH
+exec node "${0%/*}/launch.mjs" "$@"

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

@@ -12,7 +12,7 @@ description: "Specific Antigravity Hostinger MCP Server connection instructions
 
 The later stages drive the Hostinger connector through Antigravity's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, add the missing server(s) to `~/.gemini/antigravity/mcp_config.json` (Windows:
 `C:\Users\<USERNAME>\.gemini\antigravity\mcp_config.json`), which you can reach from the Agent panel's
@@ -25,12 +25,12 @@ no tokens to handle:
 {
   "mcpServers": {
     "hostinger": {
-      "command": "npx",
-      "args": ["-y", "--prefix=<home>", "@hostinger/mcp@latest"]
+      "command": "<command>",
+      "args": ["<launcher>"]
     },
     "hostinger-ecommerce": {
-      "command": "npx",
-      "args": ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>", "hostinger-ecommerce-mcp"]
     }
   }
 }

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

@@ -19,14 +19,14 @@ groups as *Check both tool groups* in `connect/SKILL.md` says:
   `hostinger-wordpress`, `hostinger-domains`, …) never include it, so a session full of
   `mcp__hostinger-*__*` tools can still be missing it.
 
-Both present → use them and move on. Either missing → register the missing server(s) at user scope
+Both present and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on. Either missing → register the missing server(s) at user scope
 now (`claude mcp list` shows what's already registered; skip those). The bootstrap already signed you
 in, so they reuse the cached sign-in (`~/.config/hostinger-mcp/credentials.json`, or
 `HOSTINGER_API_TOKEN`) and there are no tokens to handle:
 
 ```bash
-claude mcp add hostinger --scope user -- npx -y --prefix="$HOME" @hostinger/mcp@latest                                     # hosting group missing
-claude mcp add hostinger-ecommerce --scope user -- npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp  # ecommerce group missing
+claude mcp add hostinger --scope user -- "<command>" "<launcher>"                                     # hosting group missing
+claude mcp add hostinger-ecommerce --scope user -- "<command>" "<launcher>" hostinger-ecommerce-mcp  # ecommerce group missing
 ```
 
 Claude Code loads MCP servers only at startup, so follow *register, restart, resume* in

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

@@ -12,27 +12,27 @@ description: "Specific Codex Hostinger MCP Server connection instructions for th
 
 The later stages drive the Hostinger connector through Codex's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, register the missing server(s); skip one already registered. The bootstrap already signed you in, so they reuse the cached
 sign-in (`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) and there are no tokens
 to handle:
 
 ```bash
-codex mcp add hostinger -- npx -y --prefix="$HOME" @hostinger/mcp@latest
-codex mcp add hostinger-ecommerce -- npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
+codex mcp add hostinger -- "<command>" "<launcher>"
+codex mcp add hostinger-ecommerce -- "<command>" "<launcher>" hostinger-ecommerce-mcp
 ```
 
 or add them to `~/.codex/config.toml`:
 
 ```toml
 [mcp_servers.hostinger]
-command = "npx"
-args = ["-y", "--prefix=<home>", "@hostinger/mcp@latest"]
+command = "<command>"
+args = ["<launcher>"]
 
 [mcp_servers.hostinger-ecommerce]
-command = "npx"
-args = ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+command = "<command>"
+args = ["<launcher>", "hostinger-ecommerce-mcp"]
 ```
 
 Codex loads MCP servers only when it starts, so follow *register, restart, resume* in

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

@@ -13,13 +13,13 @@ description: "Specific Cursor Hostinger MCP Server connection instructions for t
 
 **Prerequisite:** Node.js 20 or newer on `PATH` (`node -v`). The published package engines require `>=20`; use Node 24 if you follow the package README.
 
-The Hostinger MCP is the npm package `@hostinger/mcp`. You do **not** need a global install — Cursor (and this session) can run it through `npx`. Prefer the unified binary `hostinger-api-mcp` (every operation). Scoped binaries such as `hostinger-hosting-mcp` are optional.
+The Hostinger MCP is the npm package `@hostinger/mcp`. You do **not** need a global install — Cursor (and this session) run it through the launcher (`~/.hostinger/mcp/`, written by the connect bootstrap), which starts the latest release with `npx` from your home folder. Never run `npx` for it directly: from the project, npx would run the project's own `node`. `<command>` and `<launcher>` below come from the bootstrap's `launcher` event (see `connect/SKILL.md`). Prefer the unified binary `hostinger-api-mcp` (every operation). Scoped binaries such as `hostinger-hosting-mcp` are optional.
 
 ### Option A — no global install (recommended)
 
 ```bash
 # Verify the package/binary is reachable
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --version
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --version
 ```
 
 ### Option B — global install
@@ -37,7 +37,7 @@ hostinger-api-mcp --version
 Check **both** tool groups, as *Check both tool groups* in `connect/SKILL.md` says: hosting
 (`mcp__hostinger__*` or `mcp__hostinger-hosting__*`) **and** ecommerce (`mcp__hostinger-ecommerce__*`).
 The scoped `mcp__hostinger-*__*` servers never include ecommerce, so they alone don't count. Both
-present → skip registration: go to Step 2 only if you still need sign-in, otherwise go to Step 3.
+present and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → skip registration: go to Step 2 only if you still need sign-in, otherwise go to Step 3.
 
 If either is missing, register the missing server(s) in `~/.cursor/mcp.json` (global, so every project and every
 later run has them). Merge them into any existing `mcpServers` rather than replacing the file.
@@ -48,12 +48,12 @@ OAuth can run:
 {
   "mcpServers": {
     "hostinger": {
-      "command": "npx",
-      "args": ["--yes", "--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-api-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>"]
     },
     "hostinger-ecommerce": {
-      "command": "npx",
-      "args": ["--yes", "--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>", "hostinger-ecommerce-mcp"]
     }
   }
 }
@@ -74,7 +74,7 @@ If the connect bootstrap already emitted `logged_in` / `success`, credentials ar
 Otherwise run the login command. It registers a dynamic OAuth client (once per machine), **opens the user's browser** to Hostinger's authorization page, listens on a localhost callback, stores tokens, and exits:
 
 ```bash
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --login
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --login
 ```
 
 (With a global install: `hostinger-api-mcp --login`.)
@@ -95,7 +95,7 @@ They are shared across every Hostinger MCP binary. Expired access tokens refresh
 To sign out later:
 
 ```bash
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --logout
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --logout
 ```
 
 **API token (optional, CI / scripts):** set `HOSTINGER_API_TOKEN` in the environment before launching Cursor. When present it always wins and no OAuth code runs. Do not commit the token.

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

@@ -12,7 +12,7 @@ description: "Specific Devin Hostinger MCP Server connection instructions for th
 
 The later stages drive the Hostinger connector through Devin's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, register the missing server(s) for Devin; skip one already registered. The bootstrap already signed you in, so they reuse the
 cached sign-in (`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) and there are no
@@ -21,18 +21,18 @@ tokens to handle.
 - **Devin CLI:**
 
   ```bash
-  devin mcp add hostinger -- npx -y --prefix="$HOME" @hostinger/mcp@latest
-  devin mcp add hostinger-ecommerce -- npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
+  devin mcp add hostinger -- "<command>" "<launcher>"
+  devin mcp add hostinger-ecommerce -- "<command>" "<launcher>" hostinger-ecommerce-mcp
   ```
 
 - **Devin app:** Settings → MCP Marketplace → **Add Your Own**, transport **STDIO**, once per server:
 
   ```json
-  { "command": "npx", "args": ["-y", "--prefix=<home>", "@hostinger/mcp@latest"] }
+  { "command": "<command>", "args": ["<launcher>"] }
   ```
 
   ```json
-  { "command": "npx", "args": ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"] }
+  { "command": "<command>", "args": ["<launcher>", "hostinger-ecommerce-mcp"] }
   ```
 
 If the tools still aren't in this session, follow *register, restart, resume* in `connect/SKILL.md`:

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

@@ -12,7 +12,7 @@ description: "Specific VS Code Hostinger MCP Server connection instructions for
 
 The later stages drive the Hostinger connector through VS Code's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, register the missing server(s) for VS Code; skip one already registered. The bootstrap already signed you in, so they reuse
 the cached sign-in (`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) and there are
@@ -25,13 +25,13 @@ no tokens to handle. Add them to `.vscode/mcp.json` (workspace) or your user `se
   "servers": {
     "hostinger": {
       "type": "stdio",
-      "command": "npx",
-      "args": ["-y", "--prefix=<home>", "@hostinger/mcp@latest"]
+      "command": "<command>",
+      "args": ["<launcher>"]
     },
     "hostinger-ecommerce": {
       "type": "stdio",
-      "command": "npx",
-      "args": ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>", "hostinger-ecommerce-mcp"]
     }
   }
 }
@@ -40,8 +40,8 @@ no tokens to handle. Add them to `.vscode/mcp.json` (workspace) or your user `se
 Or add them in two commands:
 
 ```bash
-code --add-mcp '{"name":"hostinger","command":"npx","args":["-y","--prefix=<home>","@hostinger/mcp@latest"]}'
-code --add-mcp '{"name":"hostinger-ecommerce","command":"npx","args":["--prefix=<home>","--package=@hostinger/mcp@latest","hostinger-ecommerce-mcp"]}'
+code --add-mcp '{"name":"hostinger","command":"<command>","args":["<launcher>"]}'
+code --add-mcp '{"name":"hostinger-ecommerce","command":"<command>","args":["<launcher>","hostinger-ecommerce-mcp"]}'
 ```
 
 VS Code picks up new servers and their tools become available right away, with no editor restart.

package/skills/headless/hostinger-mcp.mjs

@@ -3,20 +3,15 @@
 
 import { spawn } from 'node:child_process';
 import { homedir } from 'node:os';
+import { fileURLToPath } from 'node:url';
 
-// ── platform-safe binary names (npm/npx are .cmd on Windows), as in connect/bootstrap.mjs ──────────
-const isWin = process.platform === 'win32';
-const bin = (name) => (isWin ? `${name}.cmd` : name);
-const MCP = [bin('npx'), '-y', '--package=@hostinger/mcp@latest', 'hostinger-api-mcp'];
-// Node >= 18.20.2 / 20.12.2 refuses to spawn a .cmd/.bat without a shell
-// (CVE-2024-27980), so npx.cmd needs shell:true on Windows. Our args are all
-// fixed literals, so enabling the shell introduces no injection risk.
-const spawnShell = isWin;
+// ── always through the launcher, which runs npx from the home folder, never in the project ─────────
+const MCP = [process.execPath, fileURLToPath(new URL('./connect/launch.mjs', import.meta.url))];
 
 // One server per script run. Once it dies every pending and later call rejects, so the caller ends with
 // exit 2 rather than hanging.
 export function connect(clientName) {
-  const child = spawn(MCP[0], MCP.slice(1), { stdio: ['pipe', 'pipe', 'pipe'], shell: spawnShell, cwd: homedir() });
+  const child = spawn(MCP[0], MCP.slice(1), { stdio: ['pipe', 'pipe', 'pipe'], cwd: homedir() });
   const pending = new Map();
   let buffer = '';
   let diag = '';

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

@@ -22,7 +22,7 @@ Provision a **Hostinger Ecommerce** backend for `<domain>` and prove it is ready
 > aren't (for example, a tool connected before connect registered both servers), register it now. The
 > command for each tool is in its `connect/tools/<tool>.md`; for Claude Code:
 > ```bash
-> claude mcp add hostinger-ecommerce --scope user -- npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
+> claude mcp add hostinger-ecommerce --scope user -- "<command>" "<launcher>" hostinger-ecommerce-mcp
 > ```
 > (Or enable the **Ecommerce** MCP in the Hostinger Connector.) A newly added MCP server only loads
 > after a restart, so pause the run with *register, restart, resume* from `connect/SKILL.md`: save
@@ -49,7 +49,7 @@ Same lifecycle as `../wordpress/SKILL.md` Steps 1–2, but `type: "headless_ecom
    call a separate subdomain op first — there's no need in this flow). The response carries the
    generated domain; if it differs from the workspace dir, move
    `~/.hostinger/<old>/` → `<new>/` (if `<new>/` already exists, stop and ask instead of moving
-   into it) and update `brief.md`. Don't wait here. At the join, `node <skill>/wait.mjs setup <domain>`
+   into it) and update `brief.md`. Don't wait here. At the join, `cd "$HOME" && node <skill>/wait.mjs setup <domain>`
    returns once the setup is `completed` (see *Waiting on Hostinger* in the top-level `SKILL.md`).
    `website_type` will be `headless`.
 

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

@@ -57,7 +57,7 @@ All website/database operations below go through the Hostinger connector (`execu
    `~/.hostinger/<new>/`
    (if `<new>/` already exists, stop and ask instead of moving into it),
    update the domain in `brief.md`, and tell the user the new domain.
-3. Don't wait here. At the join, `node <skill>/wait.mjs setup <domain>` (see *Waiting on Hostinger* in
+3. Don't wait here. At the join, `cd "$HOME" && node <skill>/wait.mjs setup <domain>` (see *Waiting on Hostinger* in
    the top-level `SKILL.md`) returns once the setup is `completed`, usually at once by then. A `failed`
    setup → stop, point at hPanel.