Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dari.dev/llms.txt

Use this file to discover all available pages before exploring further.

A source bundle is the set of files uploaded from your agent project: the directory containing dari.yml at its root, plus the tracked or unignored files selected from that tree. When you publish, the dari CLI archives those files and uploads them. At runtime, agents should access the materialized source through DARI_SOURCE_BUNDLE_ROOT, which normally points to /workspace/.dari/agent-resources/source-bundle.

​
What gets uploaded

When the deploy root is inside a Git repository, the CLI uses git ls-files --cached --others --exclude-standard, so tracked files and unignored untracked files are included, while ignored files are skipped. Outside Git, the CLI walks the directory and skips common local-only paths such as .git, .dari, .venv, node_modules, .pytest_cache, __pycache__, and .DS_Store. The manifest validator enforces rules on known paths:
  • dari.yml at the root
  • Code-first TypeScript tool modules at tools/<name>/tool.ts, plus any files under declared custom-tool paths
  • skills/<name>/SKILL.md for each declared skill
  • prompts/system.md (or whatever instructions.system points at)
  • the Dockerfile path named by sandbox.dockerfile, if set
Everything else selected by Git or by the fallback directory walk is passed through as-is. There is no .dariignore; use .gitignore when publishing from a Git checkout.
Anything selected for upload ends up in the source bundle. Be deliberate about tracked files and unignored local files; secrets in the tree get baked into the sandbox template.

​
Where it lives in the sandbox

At session time, Dari materializes a source copy for managed skills, tools, and extensions under the session workspace: 
/workspace/.dari/agent-resources/source-bundle
Dari also sets DARI_SOURCE_BUNDLE_ROOT to that path for managed tool handlers and recursive agents. Prefer the environment variable in scripts so your agent does not depend on implementation details: 
SOURCE="${DARI_SOURCE_BUNDLE_ROOT:-/workspace/.dari/agent-resources/source-bundle}"
test -d "$SOURCE"
The source bundle should be treated as read-only. If an agent needs to generate a modified child agent, copy the source into a new directory under /workspace, edit that copy, and deploy the copy: 
WORK_ROOT="/workspace/.dari-work"
child_root="$WORK_ROOT/child-agent"
mkdir -p "$WORK_ROOT"
cp -a "$SOURCE" "$child_root"
# Edit $child_root/skills, $child_root/tools, $child_root/extensions, or dari.yml.
dari deploy "$child_root" --quiet

​
How the agent sees it

Built-in tools operate in the session workspace, and absolute paths are expected to stay within /workspace. Custom tool handlers receive DARI_SOURCE_BUNDLE_ROOT when they need to read files shipped with the agent. Skills are loaded from the source bundle and passed to the harness as managed skill content. Extensions are copied from the source bundle into a runtime extension directory under /workspace/.dari/agent-resources/extensions before the harness starts them. Dari does not automatically install dependencies for files outside the known paths. If you ship a package.json, requirements.txt, or custom CLI installer, add the required runtime/package entries and put install commands in sandbox.setup.script. Use a custom Dockerfile only when you need full image control.