Skip to main content
Use this page when you need to evaluate the CLI before using it with product context, private briefs, scripts, or coding agents.

​
What the CLI can access

The CLI can access Custory through the account you sign in with. It can only work with workspaces available to that account. Workspace roles still matter: read-only access is not enough for write actions.

​
Browser-based authentication

custory login uses a browser sign-in flow. The CLI prints an authorization URL and code, but it should never print your local session token. After sign-in, the CLI stores its rotating credential in your operating system credential store when available. The current stores are:
  • macOS Keychain on macOS
  • Linux Secret Service on Linux when available
  • a private local file with 0600 permissions as the fallback
If the fallback is used, the CLI warns you. The CLI discovery document is loaded from:
That route uses Cache-Control: no-store. Use --app-url only when you intentionally need the CLI to discover a non-default Custory app environment, such as a staging environment provided by Custory. The current CLI OAuth scopes are:

​
Logout and revocation

Run:
This removes the local credential and revokes the remote CLI session when possible. For MCP installations, run:
This removes the Custory MCP entry from the client config and revokes the MCP credential when the CLI has installation metadata for it.

​
Website context

When you use --website, Custory uses the public page as product context. Use public website input for pages you would be comfortable using as a product explanation. Do not rely on a website if it is outdated, too vague, blocked, private, or about a different product. Website context can produce useful structure, but it can also infer incorrectly. Review the source summary and final journey. For first-run website context, Custory applies safety limits before using the page:
  • website source policy allows up to 12 pages
  • only public http and https URLs are accepted
  • localhost, private networks, metadata hosts, and DNS results resolving to private addresses are blocked
  • sensitive routes such as login, signup, dashboard, account, admin, checkout, legal, privacy, and cookie pages are blocked
  • redirects are rechecked on every hop
  • the redirect limit is 4 hops
  • the response-size limit is 1,500,000 bytes
  • the website fetch time limit is 20 seconds

​
Private briefs

When you use --brief or --stdin, the CLI sends the text you provide to Custory as private product context. Good briefs include:
  • product summary
  • target customer
  • journey goal
  • key touchpoints
  • known friction
  • evidence gaps
Do not include:
  • secrets
  • API keys
  • access tokens
  • private customer records
  • credentials
  • source code
  • repository internals that are not needed to map the customer experience
Private brief input must be UTF-8 text. Empty input, null bytes, unsupported control characters, and input above 100,000 bytes are rejected.

​
Repository and GitHub boundary

The CLI does not ask for GitHub OAuth, repository tokens, repository cloning, or repository access. If a coding agent already has repository access, it may prepare a bounded, non-secret brief. Custory only receives what you pass through --brief or --stdin. That boundary is important. A customer journey needs product and customer context, not broad repository access.

​
JSON and logs

Use --json for machine-readable output. With --json, stdout is reserved for one JSON document. Progress and diagnostics are written to stderr. Do not paste raw logs into public issues if they include private product context. Before sharing output with support, remove workspace IDs, journey IDs, private brief text, and anything that looks like a token.

​
MCP workspace scoping

MCP installation creates a workspace-scoped credential for the selected client. Use one client installation per workspace and machine when practical. This makes revocation and auditing simpler. If a machine, client, or workspace is no longer trusted, uninstall and reinstall:

​
Stored-write verification

For journey creation, the CLI verifies important writes by reading the stored journey back from Custory. Verification checks the saved structure, not the truth of every recommendation. Your team should still review stages, steps, personas, and items against real customer evidence.

​
Report a security concern

If you believe you found a security issue, contact Custory support through the support link in the docs navigation or the Custory community channel. Include the CLI version, command category, safe error code, and redacted custory doctor output when relevant. Do not include tokens, credentials, private briefs, authorization headers, or private customer data.

​
Next step

Read Coding agents and MCP for the recommended agent trust boundary, or Automation and JSON for safe scripting patterns.