toolaby

toolaby

The Toolaby command line. It puts Toolaby — sign-in, a Free plan, paid plans, licences and subscriptions — into a Chrome extension you already have, or makes a new one for you. Toolaby takes 0.5% of a sale, or $25 a month on Pro.

It needs Node.js 20 or later. The full reference: https://toolaby.app/docs/cli

npm i -g toolaby                  # once; or run every command through `npx -y toolaby@latest …`
toolaby-cli wire <tool-id>        # in your extension's folder, on Test; signs you in first if it must
toolaby-cli wire <tool-id> --live # the same, on Live: the store build

The command is toolaby-cli: on Windows, the Command Prompt runs a toolaby.js in the current folder before a command named toolaby, and every wired folder has one. Below, toolaby <command> names each command.

In a repository you did not write, use the installed command: npx can run a toolaby the project carries, or fetch one from a registry the project's .npmrc names.

Every command acts on Test (toolaby.app/test) unless told --live (toolaby.app), as Stripe's command line does. toolaby tools lists your ids on either side.

Commands

• wire <tool-id> wires the extension in this folder to your tool. --from-extensionpay moves one that sells with ExtensionPay: its calls answered by Toolaby and its plans copied; it asks which paywall people meet first (--toolaby-popup or --own-popup without a terminal); its subscribers then move with their cards and renewal days, on the tool's Import page.
• create <tool-id> makes a new, minimal extension for your tool.
• upgrade <tool-id> replaces Toolaby's files with the current ones and leaves yours. With --live it writes the Live key, for the store build.
• check [folder] says whether the extension is wired right, in words a coding agent can act on. --browser also loads it in Chromium.
• pack [folder] makes the Chrome Web Store zip from your build.
• mcp gives coding agents Toolaby as an MCP server: claude mcp add toolaby -- npx -y toolaby@latest mcp.
• webhooks events | trigger | secret | endpoints | add | remove: the events, an example delivery (to a server on your machine too), your endpoints.
• login and logout sign the command in and out, one session per side. whoami says who you are; tools lists your tools.

toolaby-cli --help lists every flag.

What it does

toolaby login signs you in. It shows a code and opens the Toolaby dashboard; you approve the code there — as the account the dashboard is signed in to — and the command is signed in as that account from then on. It works the way GitHub's and Stripe's command lines sign in, and only ever acts on that account's own tools. It opens only Toolaby's own page, over https (or on localhost, for a server on your machine); any other address is refused and nothing is signed in.

toolaby wire <tool-id>, run in your extension's folder, wires that extension to your tool:

• it adds Toolaby's files — a small client library, a config with your tool's id and public key, and Toolaby's popup, which stands in front of yours;
• it adds what Toolaby needs to your manifest.json — the key that gives every copy one id, the storage permission, your Toolaby address under externally_connectable, and that address in a content security policy that limits connections — and never a host permission (one an earlier wiring gave is taken out); it creates a background file if you have none;
• it puts Toolaby's background in front of yours, toolaby.background.js: yours runs as it did — a classic one's importScripts() included — and Toolaby starts with it;
• it puts Toolaby's line at the foot of your popup and side panel: who is signed in, the free uses left, and Upgrade, between <!-- toolaby: account bar --> markers (accountBar: false in toolaby.config.js keeps it out);
• the rest of your code does not change. When your popup opens, Toolaby's page checks what the Free plan holds and either sends the person straight to your popup or shows sign-in, the free-use meter or the plans.

It prints what it did in a few rows — ✓ done, ! worth a look, → a step for you, with the exact code — and what to do next, in colour in a terminal (NO_COLOR turns it off). When your code sets or reads the popup itself (chrome.action.setPopup(), getPopup()), it says where; --own-popup keeps your popup in front.

If the extension is built with WXT, CRXJS or Plasmo, the command puts the same files where that build expects them and prints the few lines to paste into the framework's config, because the framework generates the manifest itself. Nothing is installed from npm.

toolaby create <tool-id> makes a new, minimal extension in a folder named after the tool, ready for Load unpacked.

toolaby pack [folder] makes the zip for the Chrome Web Store from your built extension: the manifest's key left out (the store refuses one it did not issue), and refused if the build carries a Test key or points at localhost. A store zip is public, so files that look private (*.pem, *.key, *.p12 and other keys, id_rsa and the other SSH keys, certificates, *.env, credentials.json, a service account's key such as firebase-adminsdk-….json, _netrc, source maps) are left out and named, and so is a file of any name that holds a private key or a secret (a Stripe key, live or test, a webhook secret, an AWS access key, long-term or temporary, or a secret access key, an OpenAI or Anthropic key, a Google OAuth client secret, a GitHub, Slack or npm token, a PuTTY key, a Supabase service_role key, a password in an address), read to its end, and in UTF-16 or base64 too. A Google API key is made to be in a browser: its file is packed and named, for you to restrict the key in Google Cloud. A build copies what a link in public/ points at, so pack also leaves out a file with the same bytes or text as one of the project's private files or the command's own session, in UTF-16 or base64 as well, a folder that is a git repository's own, git's history, index, refs, logs and config under any name, and a file named as an image that holds none, and it names the links in public/. A .gz or .br a build's compression plugin writes is judged by what it holds. It refuses a build when a file the manifest names would be left out, or when a public folder is itself a link into .git. --allow-private packs what it left out. Dotfiles and links are never packed. Nothing is sent anywhere.

toolaby tools lists your tools and their ids. toolaby whoami says who you are signed in as. toolaby logout signs the command out and revokes its session on the server.

Where things live

• Your session: ~/.config/toolaby/credentials.json, readable by you alone (mode 600). toolaby logout deletes it after revoking it.
• The session is per side. TOOLABY_TOKEN stands in for the file where there is no home directory (CI), and is sent to one server only: Live (toolaby.app), or the one TOOLABY_TOKEN_SERVER names — TOOLABY_TOKEN_SERVER=https://toolaby.app/test for a Test session. If that server refuses it, the session toolaby login stored for that server is used instead. TOOLABY_SERVER or --server <url> gives Toolaby another address (a server on your machine, say).

wire and create write only inside the folder they work on, and never through a symbolic link. A manifest, a framework's config or a server that names a place outside it (../, an absolute path, a link) is refused before anything is written. create writes only the files it knows a new extension has.

The files the command writes into your extension contain nothing secret: your tool's id, your Toolaby address and the public key your extension verifies licences with — the same things every copy of your extension carries once it is published.