Quick reference
Agent files
Agent files use the.agentuse extension. They combine YAML frontmatter with Markdown instructions:
model, tools, schedule, mcpServers, subagents, store, learning, sandbox, approval, channels, timeout, and maxSteps.
See Agent Syntax for the full schema.
Approval channels are configured separately from approval policy:
Environment files
AgentUse loads environment variables from the project root. Project roots are detected by walking upward from the starting directory until.agentuse/, .git/, or package.json is found. If none are found, the starting directory is the project root.
For agentuse run, .env.local takes priority when present, otherwise .env is used. You can also pass a specific file:
agentuse serve, -C selects the directory whose agents are served, while the detected project root owns .env.local, .env, .agentuse/store, and session state. Each served project loads its own .env.local or .env in that project’s worker process. Environment variables do not mix across served projects.
Use environment files for provider API keys, MCP server credentials, and runtime controls such as MAX_STEPS, LOG_LEVEL, and AGENTUSE_TELEMETRY_DISABLED.
See Environment Variables for supported variables and examples.
Global serve config
Put long-livedagentuse serve defaults in ~/.agentuse/config.json:
AGENTUSE_CONFIG=/path/to/config.json to load a different file. Project paths may start with ~ or ~/.
AgentUse runs one serve daemon at a time. Put every project that should accept /run, approval, and notification traffic into serve.projects, or pass repeated -C flags when starting the daemon.
CLI flags override config values:
AGENTUSE_API_KEY remains env-only and is not read from config.
See Webhooks and CLI Commands for serve usage.
Directory identity with ABOUT.md
Place an optional ABOUT.md in a served project root or a directory containing
agents. The dashboard uses the file to label and describe that directory. It
does not alter agent prompts, API routes, or scheduling.
Plain Markdown becomes the longer body shown on the directory detail surface:
name, description, and owner; scalar
string or numeric values are normalized for display. Unknown keys and other
value types are ignored. The body remains the longer description. AgentUse
rejects symlinked and oversized ABOUT.md files so directory identity cannot
disclose an unrelated local file or inflate API responses.
serve.brand.name labels the whole deployment; ABOUT.md labels one served
directory within it. Use serve.terms when the deployment calls projects or
folders by different nouns.
Global env defaults
Alongsideserve, ~/.agentuse/config.json accepts an env block of environment variable defaults, mirroring the env key in Claude Code’s settings.json. Use it for non-secret defaults you want applied to every run without maintaining a separate ~/.agentuse/.env file:
--mock-model <model> overrides AGENTUSE_MOCK_MODEL from any source, and --mock is satisfied by a mock model coming from the flag, the shell, ~/.agentuse/.env, or the config env block.
Keep secrets (like AGENTUSE_API_KEY and provider API keys) in an environment file rather than config.json, which is plain non-secret configuration.
Plugins
Plugins are TypeScript or JavaScript modules loaded from these directories:.agentuse/plugins/*.{ts,js}~/.agentuse/plugins/*.{ts,js}
Skills
Skills are reusable instruction packs stored asSKILL.md files. AgentUse discovers skills in this order:
.agentuse/skills/~/.agentuse/skills/.claude/skills/~/.claude/skills/
.agentuse/skills/ for project-specific skills and ~/.agentuse/skills/ for personal skills shared across projects. The .claude/skills/ locations provide compatibility with existing Claude skills.
See Skills for authoring and discovery details.
Generated files and data locations
These files are generated by features rather than hand-written as primary configuration:
See Learning, Store, Sandbox, and Session Storage for details.