← Back to PRs

#20413: docs: clarify slash command authorization model and ownerAllowFrom

by mcinteerj open 2026-02-18 22:04 View on GitHub →
docs size: XS experienced-contributor
## Summary Clarifies the slash command access model, which generated real user confusion around `commands.allowFrom` vs `commands.ownerAllowFrom`. The `ownerAllowFrom` field was entirely absent from the docs despite being in the schema. ## Changes ### New: Authorization model section Adds a three-tier summary table and explanatory prose near the top of the page: | Layer | Config | Controls | |---|---|---| | Channel access | `channels.<provider>.allowFrom` / `dmPolicy` / pairing | Who can send messages | | Command access | `commands.allowFrom` | Who can use slash commands and directives | | Owner access | `commands.ownerAllowFrom` | System prompt identity + owner-gated tools | Includes a "Common setup" callout for single-user deployments. ### New: `commands.ownerAllowFrom` documented in Config section Was entirely missing from the docs. Now documents: - What it actually controls: system prompt `Owner numbers:` injection + `whatsapp_login` tool gating - Accepted formats: plain IDs or provider-prefixed (e.g. `"whatsapp:+15551234567"`) - `"*"` behaviour: do not use — results in no owner being designated - Fallback behaviour when not set: derived from channel allowlists ### Fixed: "Owner-only" labels removed The `## Debug overrides` and `## Config updates` sections previously said "Owner-only." — both `/config` and `/debug` gate on `isAuthorizedSender` (command access), not `senderIsOwner`. Updated to "Requires command access (authorized sender)." ## Validation All claims were validated against source before merging: - `src/auto-reply/command-auth.ts` — ownership derivation chain - `src/agents/tool-policy.ts` — `OWNER_ONLY_TOOL_NAMES` (`whatsapp_login` only) - `src/agents/system-prompt.ts` — `Owner numbers:` injection - `src/auto-reply/commands-config.ts` / `commands-session.ts` — `/config`, `/debug`, `/send` command handlers - WhatsApp dock — `enforceOwnerForCommands` behaviour documented <!-- greptile_comment --> <h3>Greptile Summary</h3> Documentation-only PR that clarifies the slash command authorization model. Adds a new three-tier authorization model section (channel access, command access, owner access), documents the previously-missing `commands.ownerAllowFrom` config option, and corrects inaccurate "owner-only" labels on `/config`, `/debug`, and `/send` to reflect that they check command-level authorization (`isAuthorizedSender`), not owner-level (`senderIsOwner`). - All documentation claims were verified against source: `command-auth.ts` (ownership derivation chain), `tool-policy.ts` (`OWNER_ONLY_TOOL_NAMES` = `whatsapp_login` only), `system-prompt.ts` (`Owner numbers:` injection), `commands-config.ts` and `commands-session.ts` (command handlers use `isAuthorizedSender`) - The authorization table and prose are clear and accurately represent the three independent layers - The `"*"` caveat for `ownerAllowFrom` (results in no owner being designated) is correct per the derivation logic in `command-auth.ts:278-288` - No issues found — the changes are accurate, well-structured, and address a real documentation gap that was causing user confusion <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it contains only documentation changes with all claims validated against source code. - Documentation-only PR with no code changes. All technical claims in the documentation were verified against the source files referenced in the PR description. The authorization model description accurately reflects the code behavior. No inaccuracies found. - No files require special attention. <sub>Last reviewed commit: e59db48</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs