Security

Doxloop separates local authoring from explicit publishing. This page describes which guarantees the CLI itself enforces, and which depend on your selected agent CLI and host environment.

Trust boundaries

• .doxloop/project.json, installed generator packages, configured product

sources, and public design references are all decisions you make explicitly.

• Source text, comments, tests, generated files, and reference pages are

treated as evidence, never instructions. The authoring workflow directs agents to ignore anything embedded in them that tries to change scope, reveal secrets, weaken safeguards, contact unrelated services, or publish.

• Coding agents retain the filesystem permissions granted by their host. A

project's sources list is an authoring-policy boundary, not an operating-system sandbox.

• doxloop review runs supported agents in their read-only or plan mode.

create and update require write access to the documentation project.

Local files

The documentation contentDir must be a relative directory inside the project. Doxloop rejects a project-root, escaping, absolute, or symlinked content directory — both during authoring and at deploy time.

Network access

Authoring and validation never publish on their own. A coding agent may still have its own network access according to its own configuration, independent of Doxloop.

Design capture (doxloop capture):

• accepts only configured HTTP or HTTPS reference origins;
• captures at most three requested pages per origin;
• blocks navigation away from the configured origin; and
• blocks loopback, private, link-local, multicast, and other non-public

network destinations, storing results under the Git-ignored .doxloop/cache/reference/.

For a trusted local documentation reference only, set DOXLOOP_ALLOW_PRIVATE_REFERENCES=1 for that capture invocation.

Application guide screenshots are a separate authoring action. They require a Codex or Claude desktop app session with browser access and are not supported through their CLI workflows. Configure only a local or non-production application, use fixtures or a dedicated test account, and never expose credentials, access tokens, personal data, or customer data during capture. Published guide images belong under the generator's committed asset directory; design-reference evidence remains under .doxloop/cache/reference/.

Doxbrix API requests require HTTPS; HTTP is accepted only for loopback development. Authenticated and device-flow requests refuse redirects, so a bearer credential is never forwarded to another destination.

Credentials and publishing

Prefer doxloop login and its device flow. Environment variables (DOXLOOP_TOKEN or DOXBRIX_TOKEN) avoid placing a token in shell history; --token is intended for controlled automation. Stored credentials use user-only file permissions on operating systems that support them.

Only doxloop deploy publishes. It validates the project, builds a bundle from the contained documentation directory, and sends it to the configured Doxbrix API. External generators produce static output and aren't accepted by the native Doxbrix bundle endpoint — see Publish documentation.

Reporting a vulnerability

If you find a security issue in Doxloop itself, report it privately through the project's GitHub security advisory process rather than a public issue. Never include credentials, private product source, or unpublished vulnerability details in a public report.

Next steps