Getting help
Where to ask, what to attach, what to redact before you paste it anywhere, and the private path for a security report.
Which place you want depends on what you have: a reproduction goes to Issues, a question goes to Discussions or Discord, and anything security-shaped goes down a private path and never into either of the others.
Redact anything token-shaped before you paste it — a Chatfuel token, a Supabase key, a proxy URL with a password in it. A token that reaches a public issue is a token to rotate, and anything credential-shaped is treated as compromised whether or not anyone noticed. Rotating is one command and a fresh token; recovering a leaked one is not possible.
Something is broken
Open an issue and include the output of:
npx @chatfuel/wizard doctorThat's what a triage asks for first, and it answers most of what a bug report gets sent back for.
Before you write it, check whether the behaviour is already on the symptom list, in Limits that are not bugs, or in the error reference.
What doctor reports
It's the wizard's view of the machine before it asks anything, one row per check:
| Row | What it says |
|---|---|
node | The Node running the wizard, and the floor it's compared against (22.19.0). |
outbound proxy | The proxy variable in force and its URL with the user and password masked, or none. |
coding agent | Which coding agents are installed, and the directory each reads skills from. |
content | Whether the content comes from the published package or from a repo checkout, and where its root is. |
content lock | How many files the package pins. |
content cache | Whether the directory the fetched content goes into can be written — it writes a probe file there and removes it. |
module registry | How many modules are ready, out of how many manifests. |
content ref | Which commit a run on this machine would install from, and how it got there: resolved from the branch, taken from the cache, pinned by CHATFUEL_CONTENT_REF, or the package's own floor when the branch could not be asked. |
content pin | One real file fetched from that commit and checked against its digest. |
On a repo checkout the lock and cache rows are replaced by app template, ui sources,
api-client sources and proxy sources — the trees the scaffold copies — and by one skill: <id>
row per ready module.
A missing coding agent is a warning — the wizard offers to install one. Everything else is a hard stop, and the command exits 1. That's also why it exists in this shape: the same check is what stops a package that cannot reach its own content from being published, instead of that surfacing ten questions into somebody's first run.
Nothing it prints is a secret. Versions, paths, agent names, a commit, and a proxy URL with its
credentials replaced by ***.
You're not sure it's broken
Ask in Discussions or in Discord. "How do I…", "is this supposed to…" and "has anyone…" all belong there, and an answer usually arrives faster than a triage does.
A feature request is an issue too — or float it in Discussions first if it's more of a shape than a request. Both get read.
You found a vulnerability
Don't open an issue. Use GitHub's private vulnerability reporting on
the repository: the Security tab, "Report a
vulnerability". If that tab isn't there, email security@chatfuel.com with chatfuel-wizard in
the subject. Only the latest 0.x release of @chatfuel/wizard gets security fixes.
Don't put a real Chatfuel token or Supabase key in the report either. Anything shaped like a credential is treated as compromised — rotate it first.
The scope is the token boundary and the gate around it: the Chatfuel token and the Supabase service-role key live server-side only and must never reach the browser bundle, a client-visible response, or a log line, and the auth gate must fail closed rather than let a partial configuration through. In scope:
- exposure of the Chatfuel token or a Supabase key anywhere in scaffolded output;
- a bypass of the auth gate, over HTTP or the WebSocket relay;
- a request naming a bot that neither the auth gate nor the deployment fence vouches for;
- path traversal in the production static server;
- an upstream error naming internal infrastructure surviving the proxy's response scrubber, over HTTP or the WebSocket relay;
- a credential reaching the CLI's stdout past its log scrubber.
One route logs a secret on purpose: with AUTH_RECOVERY_LINK_LOG set, the recovery route writes
the password-reset link it minted to the server log, because on a deployment with no mail channel
that log is the delivery channel. It's off by default and refuses the route when off. Reports about
that trade-off are design feedback, not a bug class.
Out of scope: your own modifications to your scaffolded app, and Chatfuel's hosted API itself.
What this project does not support
The Chatfuel product. This is the open-source wizard and the app it writes; questions about the hosted dashboard, billing, or the API's own behaviour go to Chatfuel support at chatfuel.com. A limit in the API is not a bug here — Limits that are not bugs is the list of the ones that surface in the app.