Agent Layer

One repo-local source of truth for instructions, skills, MCP servers, and approvals across coding agents.

Agent Layer keeps AI-assisted development consistent across tools by generating each client’s required config from a single .agent-layer/ folder. Install al once per machine, run al init per repo, then run al <client> (e.g., al claude) to sync and launch.

Key properties:

• Local-first, no telemetry
• Deterministic outputs from canonical inputs
• Explicit approvals and command allowlists
• Optional per-repo runtime isolation (Codex auth, sessions, and logs; Claude settings, caches, and /login credentials)

Comparison:

Manual per-client setup	Agent Layer
duplicate instructions across multiple formats	one canonical source under .agent-layer/
inconsistent approvals and command policies	consistent approvals and allowlists
MCP servers added in one client and forgotten in another	generated MCP config for supported MCP clients
shared global state across repos	opt-in per-repo Codex auth/sessions/logs; opt-in Claude settings, caches, and /login credential isolation
no single place to review or audit changes	audit in version control

If Agent Layer improves your workflow, please consider starring the repository. Stars help new users discover the project.

---

Supported clients

MCP = Model Context Protocol (tool/data servers).

Client	Instructions	Skills	MCP servers	Approved commands
Antigravity	✅	✅	❌*	✅**
Claude Code CLI	✅	✅	✅	✅
VS Code / Copilot Chat	✅	✅	✅	✅
Codex CLI	✅	✅	✅	✅
Copilot CLI	✅	✅	✅	✅
Grok	✅	✅	✅	✅
Muse Code (opt-in)	✅	✅	✅	✅

Notes:

• Codex, Antigravity, VS Code/Copilot, Copilot CLI, Grok, and Muse consume shared skills from .agents/skills/<name>/SKILL.md.
• Claude Code consumes skills from .claude/skills/<name>/SKILL.md.
• Claude Code and Codex VS Code extension support is handled through al vscode.
• Auto-approval capabilities vary by client; approvals.mode is applied on a best-effort basis.
• *Antigravity MCP config is written to .agy/antigravity-cli/mcp_config.json using the supported serverUrl shape. agy v1.0.0 migrates that file to <gemini_dir>/config/mcp_config.json, but runtime MCP registration has not been observed yet. Run al probe agy to see the current capability matrix.
• **Antigravity approved commands are written to .agy/antigravity-cli/settings.json as a managed permissions.allow list. User passthrough in agents.antigravity.agent_specific can add other settings keys, including permissions.deny; runtime enforcement is reported by al probe agy.

Muse is optional and disabled by default. Enable [agents.muse] with enabled = true; optional model and reasoning_effort select native runtime options. al muse launches interactively, and al dispatch start --agent muse starts a headless conversation. Model suggestions come from the installed native MSP catalog; an empty catalog is reported explicitly and custom models remain available.

Muse shares generated .mcp.json with Claude, using native client filters. When enabled, this file contains resolved credentials and is private (0600); sync refuses tracked or unignored output. Muse uses its normal native home without XDG redirection. Command grants are owned, workspace-scoped native policy entries, while a project MCP hook rereads current configuration on every request. Non-YOLO runs select untrusted, disable the approval judge, and retain the sandbox and native denies. Headless runs requiring approval fail with termination evidence. The generated .claude/CLAUDE.md links to ../AGENTS.md, avoiding duplicate-instruction warnings while preserving Claude guidance. User-symlinked .claude directories retain a regular instruction copy. Both real skill trees stay in place; Muse may report shadow diagnostics while selecting each skill once. See the Muse reference for cleanup and historical-storage behavior.

---

Install

Install once per machine; choose one:

Homebrew (macOS/Linux)

brew install conn-castle/tap/agent-layer

Script (macOS/Linux)

curl -fsSL https://github.com/conn-castle/agent-layer/releases/latest/download/al-install.sh | bash

Verify:

al --version

---

Quick start

Initialize a repo (run from any subdirectory):

cd /path/to/repo
al init

Then run an agent:

al codex

Optional health check:

al doctor

Notes:

• al init prompts to run al wizard after creating the bare operational scaffold. Use al init --no-wizard to skip; non-interactive shells skip automatically.
• al init is intended to be run once per repo. If the repo is already initialized, use al upgrade plan and al upgrade to refresh template-managed files.
• By default al init first walks up for an ancestor .agent-layer/, then for an ancestor .git. To install a separate Agent Layer in a subfolder of an existing repo (for example a sub-project that needs its own .agent-layer/), pass al init --here to target the current directory.
• al upgrade is the recommended path. For CI-safe non-interactive apply, use al upgrade --yes --apply-managed-updates. Add --apply-memory-updates and/or --apply-deletions only when you explicitly want those categories. --apply-deletions never removes files under .agent-layer/tmp/; to clean up those ephemeral agent run artifacts, use --apply-tmp-deletions (destructive — requires explicit double confirmation unless combined with --yes).
• al upgrade automatically creates a managed-file snapshot and rolls changes back if an upgrade step fails. Snapshots are written under .agent-layer/state/upgrade-snapshots/.
• Agent Layer does not install clients. Install the target client CLI and ensure it is on your PATH (Antigravity agy, Claude Code CLI, Codex, Copilot CLI, Grok, VS Code, etc.).

---

Documentation sets

Universal best practices:

• Skill Design (canonical source: docs/SKILL-DESIGN.md)
• CLI Skill Design (canonical source: docs/CLI-SKILL-DESIGN.md)
• Instruction Design (canonical source: docs/INSTRUCTION-DESIGN.md)

Agent Layer approach:

• Agent Dispatch (canonical source: site/docs/agent-dispatch.mdx)
• Import Agent Skills from Git (canonical source: site/docs/skill-imports.mdx)
• Skills approach (canonical source: site/docs/skills-approach.mdx)
• DeltaSelect (canonical source: site/pages/deltaselect.mdx)
• DeepSWE benchmark guide

---

MCP server requirements (external tools)

Some MCP servers require a specific runtime or launcher to be installed locally. Agent Layer does not install these dependencies; it only runs the command you configure.

Examples:

• Node-based servers often use npx in the command field (requires Node.js + npm).
• Python/uv-based servers often use uvx in the command field (requires uv/uvx on your PATH).

If a server fails to start with “No such file or directory,” verify the command exists and is on your PATH, or set command to the full path of the executable.

Doctor MCP checks

al doctor connects to each enabled MCP server that at least one enabled client receives, and lists its tools. It waits up to 30 seconds per server before warning about connectivity, and prints a short progress indicator while checks run. When config validation fails due to unrecognized keys, al doctor reports the detected key paths, schema hints (allowed keys where applicable), and repair options (al upgrade, al wizard, or manual edits). When agents are enabled, it verifies generated client configs (for example .mcp.json, .agy/antigravity-cli/settings.json) are in sync; run al sync if they are missing or stale.

Doctor size summary

al doctor always prints a context size summary after the checks, even when every value is under its threshold and even with noise_mode = "quiet" or al --quiet doctor (it is informational, not a warning):

• Instructions — estimated tokens of the combined instruction payload, shown against instruction_token_threshold.
• Skills — estimated tokens for the skill catalog metadata (all skill names plus descriptions, loaded on every run), shown against a ~4,000-token budget.
• MCP servers — totals only: enabled servers, total tools, and total tool-schema tokens, each against its configured threshold.
• Total — the estimated sum of the always-loaded token costs (instructions + skill catalog + MCP tool schemas); any component that can't be measured is named in an (excludes …) note instead of being counted as zero.

A metric whose threshold is omitted shows (no limit set) rather than a default. If MCP servers can't be resolved the line reports the size as unavailable; if some servers are unreachable, a note states that the tool and schema totals exclude them.

---

FAQ

Why do MCP servers fail to start in VS Code on macOS?

If MCP servers that use npx are failing in VS Code, your GUI environment may not see a user-directory Node install. Install Node via Homebrew (brew install node) so VS Code can find node and npx, and avoid per-user installs that only exist in shell profiles.

Why did a VS Code setting move or change after al sync?

Agent Layer owns only the settings it writes inside the managed block (// >>> agent-layer to // <<< agent-layer) in .vscode/settings.json: chat.tools.terminal.autoApprove, chat.agentSkillsLocations, and claudeCode.allowDangerouslySkipPermissions. al sync regenerates them from .agent-layer/config.toml and .agent-layer/commands.allow, so edit those files instead of the block.

VS Code and some extensions (for example Peacock) add a new setting after the last property in the file, which can be inside the managed block. On the next al sync, Agent Layer moves every setting it does not own, with its comments, to just after the block. If text inside the block can't be read as settings, al sync fails instead of discarding it; fix or remove that text and run al sync again.

---

Version pinning (per repo, required)

Version pinning keeps everyone on the same Agent Layer release and lets al download the right binary automatically.

Upgrade contract details (event model, compatibility guarantees, migration rules, OS/shell matrix) are maintained in one canonical location: the upgrade contract (source: site/docs/upgrades.mdx).

When a release version is available, al init writes .agent-layer/al.version (for example, 0.6.0). You can also edit it manually, or set the initial pin with al init --version X.Y.Z (or --version latest). A release build of al init writes only its own templates, so it accepts only its own version; to pin a different release, run al init with that release's CLI.

When you run al inside a repo, it locates .agent-layer/, reads the pinned version when present, and dispatches to that version automatically. al init and al upgrade are exceptions: they run on the invoking CLI version so pin updates and upgrade planning are not blocked by an older repo pin.

By default, al init enables pinning in release builds by writing .agent-layer/al.version. Think of this file like a lockfile: it prevents the repo from silently changing behavior when you update your globally installed al.

Agent Layer treats .agent-layer/al.version as required for supported usage. Do not delete it. If it is missing or invalid, install a release build and run al upgrade to repair it.

Pin format:

• 0.6.0 or v0.6.0 (both are accepted)

Pin parser behavior:

• blank lines and # comments are ignored
• exactly one non-comment version line is expected
• empty/invalid/multi-version pin files produce a warning and dispatch falls back to the current CLI version until repaired

Cache location (per user):

• default: user cache dir (for example ~/.cache/agent-layer/versions/<version>/<os>-<arch>/al-<os>-<arch> on Linux)
• override: AL_CACHE_DIR=/path/to/cache

Overrides:

• AL_VERSION=0.6.0 forces a version (overrides the repo pin)
• AL_NO_NETWORK=1 disables downloads (fails if the pinned version is missing)
• AL_DOWNLOAD_TIMEOUT=2m sets how long a pinned-version download may go without receiving data before it fails (default 30s); each download may run for 10 minutes, or longer when this is 5 minutes or more

---

Updating Agent Layer

Update the global CLI:

al update

al update detects whether the running release binary is owned by Homebrew. It upgrades the formula when it is, and otherwise downloads and reruns the official installer while preserving the current install prefix.

If the installed CLI predates the al update command, update it once with brew upgrade conn-castle/tap/agent-layer for Homebrew or by rerunning the original script install command (including the same --prefix, if any).

Run al upgrade plan and then al upgrade inside the repo to apply template-managed updates. This updates .agent-layer/al.version to match the currently installed al binary and refreshes template-managed files. For a concise runbook (interactive + CI), use the one-page upgrade checklist.

Each al upgrade run writes an automatic snapshot of managed upgrade targets and auto-rolls back if an upgrade step fails. Snapshots are retained under .agent-layer/state/upgrade-snapshots/ for rollback history. To manually restore an applied snapshot, run al upgrade rollback <snapshot-id> (use the JSON filename stem from .agent-layer/state/upgrade-snapshots/ as <snapshot-id>).

To pre-warm a release binary in cache (for offline/air-gapped runs), use al upgrade prefetch --version X.Y.Z.

al upgrade also executes embedded per-release migration manifests before template writes (for example file renames/deletes and config key transitions). If the prior source version cannot be resolved, source-agnostic migrations still run and source-gated migrations are skipped with explicit report output.

Upgrade previews now include line-level diffs in both al upgrade plan and interactive al upgrade prompts. By default, each file preview is truncated to 40 lines; raise this with --diff-lines N when needed. In interactive terminals, diff hunks are colorized for scanability; non-interactive and no-color runs stay plain text.

al doctor always checks for newer releases and warns if you're behind. al init also warns when your installed CLI is out of date, unless you set --version, AL_VERSION, or AL_NO_NETWORK.

Compatibility guarantee:

• Guaranteed upgrade path is sequential release lines only (N-1 to N; example: 0.6.x to 0.7.x).
• Skipping release lines is best effort and may require additional manual migration.
• See the upgrade contract (source: site/docs/upgrades.mdx) for event categories and release-versioned migration rules.

---

Interactive setup (optional, al wizard)

Run al wizard any time to interactively configure the most important settings:

• Approvals Mode (all, mcp, commands, none, yolo)
• Agent Enablement (Antigravity, Claude, Codex, VS Code, Copilot CLI, Grok, Muse)
• Model Selection (optional; leave blank to use client defaults. Claude, Codex, Grok, Copilot CLI, and Antigravity suggestions come exclusively from the installed harnesses, queried concurrently without sync. Wizard starts discovery before the first prompt and waits only when a model picker needs the result. Discovery failure is shown and still allows the client default or a custom model; there are no bundled model lists or fallbacks. Scripted answers supply explicit values without discovery. Antigravity configuration uses harness display names, while native CLI overrides use model IDs; Claude, Codex, and Grok expose reasoning effort separately where supported)
• Feature toggles — folded into the model step as three per-agent multi-selects (Claude, Codex, and Grok). Each feature is a checkbox where checked = keep enabled and unchecking disables it; checkboxes are pre-checked to match your current config, so re-running the wizard without changes makes no edits.
  • Claude: IDE open-file reading, auto-memory, claude.ai connectors, the AskUserQuestion tool, and the Claude status line.
  • Codex: built-in apps (GitHub, Gmail, etc.), browser/computer-use, and the Codex status line.
  • Grok: project memory.
  • Unchecking writes the matching agent_specific disable key; re-checking removes it, keeping the client's native default — except Codex apps, which defaults unchecked and always writes an explicit features.apps.
  • The AskUserQuestion toggle instead writes a typed agents.claude.disable_question_tool flag, and al sync injects the permissions.deny entry plus a PreToolUse hook (merged with, never replacing, your own deny/hook entries).
  • Status line checkboxes write explicit statusline = true or statusline = false; enabling one creates the missing editable source file once and never overwrites an existing source.
• Instructions (None, Rules, or Rules and memory — imports instructions/rules.md, and for Rules and memory also instructions/memory.md plus project memory docs/templates. Fresh orders are 0 and 10; adopting existing standard files preserves their bytes and order. Fresh init defaults to Rules and memory. None preserves existing content.)
• Git tracking (choose whether .agent-layer/ and docs/agent-layer/ stay trackable or are ignored through the managed .agent-layer/gitignore.block source)
• Catalog skills (opt-in: tavily-web, playwright, find-docs, dispatch-agent, skill-sync, instruction-sync, benchmark, and development skills; tool rows require their own CLI on PATH; al doctor reports missing binaries without blocking agent launch)
• MCP Servers & Secrets (toggle default servers; safely write secrets to .agent-layer/.env)
• Warnings (enable/disable warning checks; threshold values use template defaults)

General development skills and the find-docs, playwright, and tavily-web tool skills are authored in nicholasjconn/skills. The wizard imports their exact grouped paths into .agent-layer/skills-imported/; explicit al skills pull updates content independently of CLI upgrades. Legacy local copies are protected during upgrades and adopted only after the wizard previews their conversion. dispatch-agent, skill-sync, instruction-sync, and benchmark remain bundled. See the skills guide for dependency and ownership details.

Wizard backups are stored in .agent-layer/state/wizard-backups/. Each wizard apply replaces the latest backup for the files it writes. After a successful upgrade and sync, al upgrade moves legacy .agent-layer/config.toml.bak and .agent-layer/.env.bak files there, retaining conflicts with numbered .legacy-N suffixes. Explicit cleanup removes both current and legacy backups.

Non-interactive profile mode is also available:

# Preview-only diff against current .agent-layer/config.toml
al wizard --profile /path/to/profile.toml

# Apply profile + run sync
al wizard --profile /path/to/profile.toml --yes

# Remove wizard backups when no longer needed
al wizard --cleanup-backups

Profile mode replaces the entire config and previews its diff. Include the intended [[skills.imports]] blocks in replacement profiles to retain ownership; removing them leaves locked skills and content for explicit reconciliation with normal al skills import commands.

Controls:

• Arrow keys: Navigate
• Space: Toggle selection (multi-select)
• Enter: Confirm/Continue
• Esc: Go back to the previous wizard step (first step asks for exit confirmation)
• Ctrl+C: Cancel immediately

The wizard rewrites config.toml in a deterministic preferred section order and creates backups (.bak) before modifying .agent-layer/config.toml or .agent-layer/.env. Inline comments on modified lines may be moved to leading comments or removed; the original formatting is preserved in the backup files. When prompted for required MCP secrets, type skip to disable that server for this run or cancel to exit without applying changes.

---

What gets created in your repo

Bare al init creates the operational scaffold. The wizard can seed instruction files, project memory, and catalog skills, and al sync creates generated client files.

User configuration (gitignored by default, but can be committed)

• .agent-layer/
• config.toml (main configuration; human-editable)
• al.version (repo pin; required)
• instructions/ (project-owned Markdown files, explicitly ordered in config)
• instructions-imported/ and instructions.lock.json (Git-backed editable instructions and upstream state)
• skills/ (created empty by bare init; the wizard catalog can add <name>/SKILL.md directories)
• tmp/runs/ (runtime scratch directory)
• commands.allow (approved shell commands; line-based)
• gitignore.block (managed .gitignore block template; customize here)
• .gitignore (ignores repo-local launchers, template copies, and backups inside .agent-layer/)
• .env (tokens/secrets; gitignored)

Repo-local launchers and template copies live under .agent-layer/ and are ignored by .agent-layer/.gitignore.

Project memory (optional; teams can commit or ignore)

The wizard's Rules and memory instruction choice creates missing memory docs and templates. Bare init does not create docs/agent-layer/.

Common memory files include:

• docs/agent-layer/ISSUES.md
• docs/agent-layer/BACKLOG.md
• docs/agent-layer/DECISIONS.md
• docs/agent-layer/COMMANDS.md
• docs/agent-layer/CONTEXT.md

Generated client files (gitignored by default)

Generated outputs are written into the repo in client-specific formats (examples):

• Instruction shims: AGENTS.md, .claude/CLAUDE.md, .github/copilot-instructions.md
• MCP + client configs: .mcp.json, .agy/antigravity-cli/mcp_config.json, .claude/settings.json, .codex/, .copilot/mcp-config.json, .grok/config.toml
• Shared Antigravity settings: .agy/antigravity-cli/settings.json (Agent Layer patches its managed model, permissions.allow, and agent_specific paths while preserving native settings)
• Shared skills: .agents/skills/
• Antigravity notification plugin: .agents/plugins/agent-layer-chime/
• Grok notification hook: .grok/hooks/agent-layer-chime.json
• Claude skills: .claude/skills/
• VS Code integration: .vscode/mcp.json and an Agent Layer-managed block in .vscode/settings.json

---

Configuration (human-editable)

You can edit all configuration files by hand. al wizard updates config.toml (approvals, agents/models, MCP servers, warnings), .agent-layer/.env (secrets), and .agent-layer/gitignore.block (Agent Layer folder tracking). It can also seed missing instruction and memory files, explicitly import/adopt or remove catalog skills (including Git-backed development skills), and seed missing statusline source files; it does not refresh existing instruction files, overwrite existing statusline sources, or touch commands.allow.

.agent-layer/config.toml

Edit this file directly or use al wizard to update it. This is the only structured config file.

Example:

[approvals]
# one of: "all", "mcp", "commands", "none", "yolo"
mode = "all"

[notifications]
# Optional best-effort local chime for filtered top-level completion events.
# Absent or false disables it. The handler uses a native system sound command.
# Codex Stop hooks cannot prove semantic task completion; see Notifications below.
chime = false

[agents.antigravity]
enabled = true
# Antigravity model/reasoning selection is a single agy model display string.
# al wizard writes this key and fresh wizard setups default it to high reasoning.
model = "Gemini 3.1 Pro (High)"

[agents.claude]
enabled = true
# model is optional; when omitted, Agent Layer does not pass a model flag and the client uses its default.
# model = "..."
# reasoning_effort is optional; Claude Code applies it where the active model supports it.
# reasoning_effort = "medium" # low | medium | high | xhigh | max (custom values pass through with a warning)
# Note: "max" is session-only (passed via --effort CLI flag) and is not written to .claude/settings.json.
# disable_question_tool blocks Claude Code's AskUserQuestion tool. When true, al sync injects
# permissions.deny + a PreToolUse hook into .claude/settings.json (merged with any agent_specific
# entries; the hook also enforces the block under YOLO). Run `al wizard` to set it.
# disable_question_tool = true
# statusline writes a Claude Code status line. Run `al wizard` or interactive
# `al upgrade` to enable it and seed .agent-layer/claude-statusline.sh once; on
# sync that source is copied to .claude/claude-statusline.sh and statusLine is
# wired into .claude/settings.json. Absent means disabled. Requires jq on PATH.
# statusline = true
# Optional `agent_specific` passthrough for Claude (arbitrary JSON keys).
# Object values are deep-merged into .claude/settings.json; arrays and scalar values are replaced at their key.
# Overlapping managed keys, such as permissions.allow, override Agent Layer-managed
# values and trigger a sync warning. permissions.deny is additive and does not warn.
# Optional "disable" toggles (run `al wizard` to set these). Each keeps Claude
# Code's native default until enabled; uncomment to opt in.
# agent_specific.env.CLAUDE_CODE_AUTO_CONNECT_IDE = "false" # stop reading files open in the IDE
# agent_specific.env.ENABLE_CLAUDEAI_MCP_SERVERS = "false"  # disable claude.ai app connectors
# agent_specific.autoMemoryEnabled = false                  # disable auto-memory (does not affect CLAUDE.md)
# [agents.claude.agent_specific]

[agents.claude_vscode]
enabled = true

[agents.codex]
enabled = true
# model is optional; when omitted, Agent Layer does not pass a model setting and the client uses its default.
# model = "gpt-5.6-sol"
# reasoning_effort is optional; when omitted, the client uses its default.
# reasoning_effort = "xhigh" # codex only
# local_config_dir sets CODEX_HOME=<repo>/.codex for per-repo auth, sessions,
# logs, and other Codex runtime state. When absent or false, Agent Layer does
# not set CODEX_HOME, so Codex uses its normal global/project config layering.
# local_config_dir = false
# statusline writes Codex's native status line from the editable
# .agent-layer/codex-statusline.toml fragment. Run `al wizard` or interactive
# `al upgrade` to enable it and seed the source once. Absent means disabled.
# statusline = true
# Optional `agent_specific` passthrough for Codex (arbitrary TOML tables/keys).
# These are patched into .codex/config.toml and can override top-level managed keys.
# Agent Layer seeds [projects."<repo root>"] trust_level = "trusted" only when
# that exact project entry is absent.
# [agents.codex.agent_specific]
# [agents.codex.agent_specific.features]
# apps = false              # disable built-in Codex apps (GitHub, Gmail, etc.) to reduce tool surface
# plugins = false           # disable Codex plugins and plugin-provided skills/tools
# browser_use = false       # disable Codex browser/computer-use tools
# in_app_browser = false    # disable the in-app browser
# computer_use = false      # disable screen/computer control
# multi_agent = true
# prevent_idle_sleep = true

[agents.vscode]
enabled = true

[agents.copilot_cli]
enabled = true
# model is optional; when omitted, Agent Layer does not pass a model flag and the client uses its default.
# model = "..."
# reasoning_effort is not currently supported for Copilot CLI in Agent Layer.

[agents.grok]
enabled = false
# model is optional; when omitted, Agent Layer does not pass a model flag and the client uses its default.
# model = "grok-4.6" # grok-4.6 | grok-4.5
# reasoning_effort is optional; Grok applies it where the active model supports it.
# reasoning_effort = "high" # none | minimal | low | medium | high | xhigh | max
# GROK_HOME is always <repo>/.grok-config for al grok, dispatch, and al vscode.
# disable_memory = true   # force --no-memory / GROK_MEMORY=0
# Optional project plugin configuration may be placed under
# [agents.grok.agent_specific.plugins]. Other Grok settings are user-level.

[agents.muse]
enabled = false
# Optional model and reasoning_effort use the installed native Muse catalog.
# Muse uses its normal user home; there is no local_config_dir option.

[mcp]
# Secrets belong in .agent-layer/.env (never in config.toml).
# MCP servers here are the *external tool servers* that get projected into client configs.
# A fresh `al init` ships no servers; run `al wizard` to pick from a curated catalog (context7, tavily, fetch, playwright) or hand-author your own block as shown below.

[[mcp.servers]]
id = "example-api"
enabled = true
transport = "http"
# http_transport = "sse" # optional: "sse" (default) or "streamable"
url = "https://example.com/mcp"
headers = { Authorization = "Bearer ${AL_EXAMPLE_TOKEN}" }

[[mcp.servers]]
id = "local-mcp"
enabled = false
transport = "stdio"
command = "my-mcp-server"
args = ["--flag", "value"]
env = { MY_TOKEN = "${AL_MY_TOKEN}" }

[warnings]
# Optional thresholds for warning checks. Omit or comment out to disable.
# Warn when a newer Agent Layer version is available during sync runs.
version_update_on_sync = true
# Warning output noise control: "default" keeps all warnings, "reduce" hides suppressible non-critical warnings,
# "quiet" suppresses agent-layer informational output (warnings, update checks, dispatch banners). Configured
# quiet does not hide `al doctor` output; use `al --quiet doctor` to suppress warning-only doctor output.
noise_mode = "default"
instruction_token_threshold = 10000
mcp_server_threshold = 15
mcp_tools_total_threshold = 60
mcp_server_tools_threshold = 25
mcp_schema_tokens_total_threshold = 30000
mcp_schema_tokens_server_threshold = 20000

agent_specific passthrough keys are copied into provider-native settings. Grok accepts only [agents.grok.agent_specific.plugins] because its project config ignores other user-level settings. Codex and Claude warn when supported passthrough keys collide with Agent Layer-managed keys; Antigravity rejects agents.antigravity.agent_specific.model because agents.antigravity.model is the only model source. .codex/config.toml is shared Codex state: al sync refreshes known Agent Layer-managed entries, preserves unrelated Codex/user runtime entries, and seeds current repo trust only when that exact project entry is absent.

Notifications ([notifications])

Set chime = true to project one Agent Layer-owned, project-shareable Stop handler into enabled Claude, Codex, Antigravity, and Grok clients. The handler chimes only for a main Claude turn with no continuation, background task, or scheduled wakeup; an initial Codex turn stop with no active continuation; an idle, normal, error-free Antigravity stop; or a Grok main-session end_turn stop with no continuation, background task, or scheduled wakeup. Malformed events stay silent. Existing user hook groups remain alongside the managed handler.

This is best-effort notification, not proof of correctness or semantic task completion. Codex runs matching hooks concurrently, so its initial Stop can chime before another hook requests continuation; filtering later stop_hook_active events prevents repeat chimes but cannot eliminate every early first chime. No global provider settings, Codex notify, or repo-local CODEX_HOME mode are required.

al hook chime uses macOS /usr/bin/afplay with the system Blow sound. On Linux it uses canberra-gtk-play --id=complete when that command is available on PATH; no sound asset is bundled, and Linux systems without the command remain silent with a diagnostic. Generated commands invoke the installed al on PATH and fail open with each provider's valid allow response, so a missing handler or sound failure cannot alter agent control flow. Other operating systems are unsupported. Codex project hooks still require trusted project config and enabled hooks; Grok project hooks, MCP, and LSP use the seeded repo-local folder-trust store under .grok-config/trusted_folders.toml; Claude hooks can be disabled by --bare, --safe-mode, or policy settings. Gemini CLI is not projected because Antigravity is Agent Layer's supported Google client.

Built-in placeholders

Agent Layer provides a built-in ${AL_REPO_ROOT} placeholder for file paths in MCP server configs. It expands to the absolute repo root during al sync and al doctor, and it does not need to be in .env. Paths that start with ${AL_REPO_ROOT} or ~ are expanded and normalized; other relative paths are passed through as-is.

Example:

[[mcp.servers]]
id = "filesystem"
enabled = false
transport = "stdio"
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "${AL_REPO_ROOT}/."]

Restricting a server to specific clients

Use the optional clients field on an [[mcp.servers]] entry to control which clients receive a server. If you omit clients, the server is projected to all supported clients.

clients = ["antigravity", "codex", "copilot", "grok"]  # VS Code excluded; see the root .mcp.json constraint below

This is useful when a client already covers the capability natively — for example, excluding VS Code/Copilot Chat for a file-search or filesystem server, where an MCP server would only duplicate built-in functionality and increase context window usage.

When VS Code is enabled, entries in the generated root .mcp.json must also select vscode, because VS Code imports that file. That file holds Claude-selected entries when either Claude integration is enabled and Muse-selected entries when Muse is enabled. Include vscode, omit clients to select all, or disable every enabled Muse, Claude, or Claude VS Code integration selecting the server.

HTTP transport (http_transport)

For HTTP MCP servers, http_transport controls how al doctor connects:

• sse (default)
• streamable

Omit http_transport to default to sse. Muse-selected HTTP servers require streamable; use client selection to exclude Muse from SSE servers.

Warning thresholds ([warnings])

Warning thresholds are optional. When a threshold is omitted, its warning is disabled. Values must be positive integers (zero/negative are rejected by config validation). al sync uses instruction_token_threshold and, when version_update_on_sync = true, warns if a newer Agent Layer release is available. al doctor evaluates all configured MCP warning thresholds.

Set version_update_on_sync = true to opt in to update warnings during al sync and al <client>; omit it or set it to false to keep update warnings limited to al init, al doctor, and al wizard. Set noise_mode = "default" to keep all warnings (recommended), noise_mode = "reduce" to hide only suppressible non-critical warnings, or noise_mode = "quiet" to suppress agent-layer informational output. Errors still print, client output is unaffected, and al doctor prints warnings by default regardless of noise mode. For one-off doctor runs, al --quiet doctor suppresses warning-only doctor output while still showing failures. The al doctor size summary is informational and always prints, regardless of noise mode or --quiet.

Use al <client> --quiet (or -q) for one-off quiet runs; the flag always wins over config.

Approvals modes (approvals.mode)

These modes control whether the agent is allowed to run shell commands and/or MCP tools without prompting. Edit them to match your team's preferences; al wizard can update approvals.mode.

• all: auto-approve both shell commands and MCP tool calls (where supported)
• mcp: auto-approve only MCP tool calls; shell commands still require approval (or are restricted)
• commands: auto-approve only shell commands; MCP tool calls still require approval
• none: approve nothing automatically
• yolo: skip all permission prompts where the client supports it (sends --dangerously-skip-permissions to Claude and Antigravity, approval_policy=never + sandbox_mode=danger-full-access + web_search=live to Codex, --yolo to Copilot CLI, --permission-mode bypassPermissions --always-approve to Grok, --yolo to Muse); intended for sandboxed/ephemeral environments

Client notes:

• Some clients do not support all approval types; Agent Layer generates the closest supported behavior per client.

Codex may still deny or override these settings if its requirements.toml disallows them.

How approvals reach a dispatched agent

al dispatch runs agents headlessly, where no one can answer a prompt. For Codex and Claude, Agent Layer sends the approval policy on the command line:

approvals.mode	Codex sandbox_mode	Claude --permission-mode
none, mcp	read-only	dontAsk
commands, all	workspace-write	acceptEdits
yolo	danger-full-access	--dangerously-skip-permissions

Muse dispatch uses native approvals and the command/MCP grants projected by sync. Outside yolo, it disables the approval judge; pending tool approval fails the invocation and triggers provider termination. Native Muse auto-cancels user-input requests. Only explicit yolo adds --yolo. See Agent Dispatch for details.

Editing capability follows command approval, because Codex has no separate edit-approval rule: its sandbox is what permits or denies unprompted edits. Under none and mcp a dispatched agent can read and answer questions but cannot change files.

Claude applies a project's permissions.allow rules only after you accept its workspace trust dialog, and that dialog never appears under -p. Dispatch therefore also passes the allowlisted commands and MCP servers as --allowedTools, so the same approvals apply whether or not the repository has been trusted interactively. deny rules and managed policy are unaffected and still win.

Under commands and all, a dispatched Codex agent works inside the sandbox Codex itself uses by default for a version-controlled folder. That envelope has limits worth knowing:

• Writes are confined to the working directory and temporary directories.
• .git is not writable. Codex protects .git, .agents, and .codex inside writable roots, so a dispatched agent cannot stage, commit, or rewrite refs. Interactive users approve that escalation; a headless run has no one to ask.
• Network access is off, including loopback. An agent cannot bind a test server or fetch dependencies. Set sandbox_workspace_write.network_access through agents.codex.agent_specific if a repository needs it.

Explicit provider settings stay authoritative: agents.codex.agent_specific.sandbox_mode and agents.claude.agent_specific.permissions.defaultMode are never overridden by dispatch.

If a dispatched Claude agent is denied a tool call, the dispatch fails with the denied tool name. Claude itself reports such a run as a success with a plausible final answer, so Agent Layer treats a denial as a failure rather than passing that answer through.

Secrets: .agent-layer/.env

API tokens and other secrets live in .agent-layer/.env (always gitignored). The file is optional: when no secrets are needed, it can be absent.

Important: Only environment variables that start with the AL_ prefix are sourced from .env (others are ignored). This convention avoids conflicts with your shell environment and ensures Agent Layer's variables don't override existing environment variables when VS Code terminals inherit the process environment.

Example keys:

• AL_CONTEXT7_API_KEY
• AL_TAVILY_API_KEY
• AL_GITHUB_PERSONAL_ACCESS_TOKEN (only when using the optional GitHub MCP server)

Non-empty values in your existing process environment take precedence. .agent-layer/.env fills only keys that are missing or empty in your environment, and empty values in .agent-layer/.env are ignored (so template entries cannot override real tokens). This behavior is consistent whether launching via al commands or repo-local launchers like open-vscode.app, open-vscode.sh, or open-vscode.command.

Instructions: .agent-layer/instructions/

These files are user-editable; customize them for your team's preferences.

Each file has one required nonnegative order in [[instructions.local]] or [[instructions.imports]]; files from both tiers are concatenated numerically. Zero and gaps are valid; duplicate orders or filenames fail before projection. Names need no numeric prefix. Each block selects exactly one regular Markdown file; instruction wildcards and exclusions are unsupported.

[[instructions.imports]]
repository = "https://github.com/nicholasjconn/skills.git"
selectors = ["instructions/rules.md"]
order = 0

[[instructions.imports]]
repository = "https://github.com/nicholasjconn/skills.git"
selectors = ["instructions/memory.md"]
order = 10

[[instructions.local]]
selectors = ["conventions.md"]
order = 40

al instructions provides add/remove/status/diff/pull/resolve/reset/push with the skills flags and policies; add requires --order. al sync and status are offline. Pull merges local edits against genuine locked upstream; push excludes local files and order. Commit imported files and instructions.lock.json together. Software upgrades preserve instruction bodies. Legacy ordering is established offline by al upgrade or accepted wizard changes; sync reports those commands until migration completes. Wizard Rules/Memory imports require Git access.

Skills: .agent-layer/skills/

User-managed skills live in .agent-layer/skills/; skills managed through al skills live in .agent-layer/skills-imported/. These canonical source tiers define the workflows you want your agents to run.

In a project that commits .agent-layer/, the generated .agent-layer/.gitignore leaves both .agent-layer/skills-imported/ and its .agent-layer/skills.lock.json upstream state tracked, so a fresh clone or CI run has the exact imported skill content — including local edits — without a network al skills pull. Commit the two together: the imported tier is fully managed, and a skill directory with no lock entry is a loud error rather than a silent shadow. Only .agent-layer/skills-imported/.staging/, the import transaction's scratch space, stays ignored.

The root .gitignore block ships with /.agent-layer/, which ignores the whole directory and takes precedence over the above. To commit your Agent Layer configuration and imported skills, remove that line from .agent-layer/gitignore.block and re-run al sync; .agent-layer/.env stays ignored either way.

Agent Layer aligns with the Agent Skills specification, and al doctor validates configured skills against agentskills-aligned conventions.

• Source format:
  • Directory: <source-tier>/<name>/SKILL.md (uppercase filename required)
• Frontmatter fields:
  • Required: name, description
  • Additional fields are accepted without interpretation and projected unchanged.
• name validation (al doctor):
  • NFKC-normalized and compared against the canonical source name (filename stem or directory name) using normalization-aware matching
  • Maximum 64 Unicode characters, lowercase letters/digits/hyphens only, and no leading/trailing/consecutive hyphens
• Description limit: maximum 1024 Unicode characters per skill.
• Catalog warning (al doctor): all skill names plus descriptions (the always-loaded catalog metadata) should stay at or below an estimated ~4,000 tokens.
• Size recommendation (al doctor): warns when a skill source exceeds 500 lines.
• Missing or empty name or description is a load/sync error.
• Lowercase-only skill.md fails with rename guidance; having both filename spellings is ambiguous and also fails.
• Skill trees may contain only real directories and regular files; symlinks and other node types fail with the offending path.
• Shared-skill clients consume disposable output from .agents/skills/<name>/SKILL.md; Claude consumes disposable output from .claude/skills/<name>/SKILL.md.
• Agent Layer owns both client skill roots exclusively. Sync replaces each enabled root wholesale, removes extra content, and removes the root when its projection is disabled. Edit only the canonical source tiers.
• Workflow guidance is provided by individual skill sources under .agent-layer/skills/.

Approved commands: .agent-layer/commands.allow

• One command prefix per line.
• Used to generate each client’s “allowed commands” configuration where supported.

---

Skill sync

Skills are synced natively to Agent Skills directories with full subdirectory support (scripts/, references/, assets/). Shared-skill clients use .agents/skills/; Claude uses .claude/skills/. No MCP server is involved; al sync copies skill sources directly into enabled client skill folders. See docs/SKILL-CLIENT-SPEC.md for the source-cited client support matrix.

---

Agent Dispatch

Agent Dispatch is a fully asynchronous, stateful interface with two surfaces over one backend: MCP tools for agents, and the CLI for humans and scripts.

Agents use the built-in agent-layer MCP server, which al sync projects into every enabled Codex, Claude, Antigravity, VS Code, Copilot CLI, Grok, and Muse client. It exposes dispatch_options, dispatch_start, dispatch_wait, dispatch_continue, dispatch_cancel, dispatch_inspect, and dispatch_output. Antigravity's current probe baseline accepts the generated MCP config but does not expose its tools at runtime; run al probe agy before relying on it as a calling client. It remains available as a dispatch target. Muse is also a supported dispatch target. The generated stdio launcher enters the repository root before invoking al, so the global shim honors that repository's .agent-layer/al.version even when the MCP client starts servers from another directory. Repositories whose MCP files were generated by an older release can refresh only those generated files without changing their pin by running AL_VERSION=<new-version> al sync once. dispatch_wait blocks for 30 minutes by default, so a coordinator waits inside one tool call instead of polling; dispatch_cancel requests cancellation. termination_confirmed separately reports durable proof that execution stopped.

The equivalent CLI:

al dispatch options
al dispatch start --agent codex --prompt-file prompt.md
al dispatch start --agent muse --prompt-file prompt.md
al dispatch reserve
al dispatch start --reservation <handle> --agent codex --prompt-file prompt.md
al dispatch wait <handle-or-invocation-id>
al dispatch inspect <handle-or-invocation-id>
al dispatch output <handle-or-invocation-id> --artifact final_answer
al dispatch continue <handle> --prompt "Review the revision."
al dispatch cancel <handle-or-invocation-id>

options reports available agents, configured defaults, and supported overrides. start and continue return immediately with a conversation handle and immutable invocation_id. Use the ID to track that exact invocation across continuations. wait blocks for a bounded interval — eight minutes on the CLI — and returns running (or reserved for a reservation not yet started) when it expires without changing the invocation, so callers wait again on the same invocation. Use --condition termination_confirmed to wait for stop confirmation. inspect returns promptly; output retrieves bounded final-answer or event text, including partial output on failure or cancellation. Completed output is stored in the immutable Markdown file named by result_path. Every successful command returns one JSON object; wait also writes its terminal JSON result before a non-zero failed-invocation exit. Programmatic callers can reserve a conversation name before launching with start --reservation <handle>. A repeated start of a retained reservation errors with guidance to inspect the invocation and continue only when available; it does not launch again. After retention removes the reservation, its three-word handle can be reused, so callers must stop retrying it by then. This is CLI only. For the complete contract, including the MCP tool schemas and the dispatch.mcp_wait_timeout_minutes / dispatch.mcp_tool_timeout_minutes settings, see docs/AGENT-DISPATCH.md.

---

VS Code (Codex + Claude extensions)

al vscode is the single command for launching VS Code with both Codex and Claude extension support. It is enabled when either [agents.vscode] or [agents.claude_vscode] is set to enabled = true in config.toml.

• When [agents.vscode] is enabled and [agents.codex] local_config_dir = true is set, CODEX_HOME=<repo>/.codex is set for the Codex extension. Otherwise Agent Layer preserves any inherited CODEX_HOME.
• When [agents.grok] is enabled, al grok, Grok dispatch, and al vscode set GROK_HOME=<repo>/.grok-config. Grok auth and sessions are therefore per repository; a new repo-local home may require login even when global Grok is already authenticated. If Grok is disabled, al vscode clears only a stale repo-local GROK_HOME.
• When [agents.claude_vscode] is enabled, Claude files (.mcp.json, .claude/settings.json) are generated. YOLO mode sets claudeCode.allowDangerouslySkipPermissions in .vscode/settings.json.
• When [agents.claude] local_config_dir = true is set, al claude sets CLAUDE_CONFIG_DIR for per-repo settings, caches, and /login credentials. For al vscode, CLAUDE_CONFIG_DIR is set only when both local_config_dir = true and [agents.claude_vscode] is enabled; otherwise al vscode clears only stale repo-local values and preserves user-defined non-repo values. This is opt-in; when disabled (the default), Claude uses your global ~/.claude/ configuration. For al claude only, a user-set CLAUDE_CONFIG_DIR pointing outside the repo is preserved even when local_config_dir is disabled. On macOS, Claude Code keys its Keychain entry to CLAUDE_CONFIG_DIR and falls back to .credentials.json there if the Keychain write fails; Linux and Windows use .credentials.json under that directory. Other authentication modes may use external credential sources. See Claude Code authentication.
• VS Code settings are generated when either agent is enabled.
• Supports --no-sync to skip sync before opening VS Code.

The Codex VS Code extension reads CODEX_HOME and the Claude extension reads CLAUDE_CONFIG_DIR from the VS Code process environment at startup.

Agent Layer provides repo-specific launchers in .agent-layer/ that invoke al vscode; they set CODEX_HOME only when [agents.codex] local_config_dir = true is enabled, and set CLAUDE_CONFIG_DIR when both local_config_dir and agents.claude_vscode are enabled:

Launchers:

• macOS: open-vscode.app (recommended; VS Code in /Applications or ~/Applications) or open-vscode.command (uses code CLI)
• Linux: open-vscode.desktop or open-vscode.sh (uses code CLI; shows a dialog if missing)

These launchers invoke al vscode, so the al CLI must be available on your PATH. al vscode also runs launch preflight checks and fails fast with guidance when code is missing on PATH or .vscode/settings.json has a managed-block marker conflict.

If you use the CLI-based launchers, install the code command from inside VS Code:

• macOS: Cmd+Shift+P -> "Shell Command: Install 'code' command in PATH"
• Linux: Ctrl+Shift+P -> "Shell Command: Install 'code' command in PATH"

Note: Codex authentication is per repo only when local_config_dir = true is enabled under [agents.codex]; in that mode each repo uses its own CODEX_HOME and may require reauthentication. If local_config_dir = true is enabled under [agents.claude], Claude settings, caches, and /login credentials are isolated per repo through CLAUDE_CONFIG_DIR. On macOS, Claude Code keys its Keychain entry to that directory and falls back to .credentials.json there if the Keychain write fails; Linux and Windows use .credentials.json under the directory. Other authentication modes may use external credential sources. See Claude Code authentication.

For contributor-level implementation details, see docs/architecture/vscode-launch.md.

---

Temporary artifacts (agent-only)

Some workflows write agent-only artifacts such as plans, task lists, and reports. They are working state rather than product documentation, but people can inspect them when reviewing or recovering a run.

Artifacts always live under .agent-layer/tmp/ and use a unique, concurrency-safe name:

• .agent-layer/tmp/<workflow>.<run-id>.<type>.md
• run-id = YYYYMMDD-HHMMSS-<short-rand> (uses bash $RANDOM; bash is required)
• Multi-file workflows reuse the same run-id for all files.
• Common type values: report, plan, task, context.

Workflows echo the artifact path in the chat output. There are no path overrides or environment variables for this. Leave artifacts in place for later inspection unless a user explicitly asks to remove them. Interrupted-run artifacts are harmless and can help with recovery.

---

CLI overview

Common usage:

al agy
al claude
al codex
al copilot
al grok
al muse
al vscode

Passing flags to clients

al <client> forwards any extra arguments to the underlying client. If you need to use Agent Layer flags as well, place -- before the client arguments.

Examples:

al claude -- --help
al vscode --no-sync -- --reuse-window

--no-sync is an Agent Layer flag and must appear before --; anything after -- is passed directly to the client. For an explicit false value, use --no-sync=false (space-separated values like --no-sync false are not supported and will be passed through).

Other commands:

• al init — initialize the bare .agent-layer/ operational scaffold and .gitignore
• al update — update the global CLI through Homebrew or the official release installer, matching the current installation
• al upgrade — apply template-managed updates and update the repo pin (interactive by default; non-interactive requires --yes plus one or more apply flags; line-level diff previews shown by default, --diff-lines N to raise per-file preview size; automatic snapshot + rollback on failure)
• al upgrade plan — preview plain-language categorized template/pin changes and readiness actions with line-level diff previews (--diff-lines N to raise per-file preview size)
• al upgrade prefetch — download and cache a release binary (use --version X.Y.Z on dev builds; useful for offline/CI cache warm-up)
• al upgrade rollback <snapshot-id> — restore an applied upgrade snapshot (snapshot IDs are JSON filenames in .agent-layer/state/upgrade-snapshots/; use al upgrade rollback --list to discover available IDs)
• al upgrade repair-gitignore-block — restore .agent-layer/gitignore.block from templates, keeping your /.agent-layer/ and /docs/agent-layer/ tracking choices, and reapply the root .gitignore managed block
• al sync — regenerate configs without launching a client
• al probe agy — run the Antigravity capability probe and print JSON
• al probe grok — run the Grok capability probe and print JSON
• al dispatch start — start a supported headless target through Agent Dispatch (see the Agent Dispatch section)
• al doctor — check common setup issues and warn about available updates
• al wizard — interactive setup wizard plus profile mode (--profile) and backup cleanup (--cleanup-backups)
• al completion — generate shell completion scripts (bash/zsh/fish, macOS/Linux only)

---

Shell completion (macOS/Linux)

The completion command is available on macOS and Linux only.

“Shell completion output” is a snippet of shell script that enables tab-completion for al in your shell.

Typical behavior:

• al completion bash prints a Bash completion script to stdout
• al completion zsh prints a Zsh completion script to stdout
• al completion fish prints a Fish completion script to stdout
• al completion <shell> --install writes the completion file to the standard user location

This enables:

• al <TAB> to complete supported subcommands (agy/claude/codex/copilot/grok/muse/vscode/sync/…)

Notes:

• Zsh may require adding the install directory to $fpath before compinit (the command prints a snippet when needed).
• Bash completion requires bash-completion to be enabled in your shell.

---

Git ignore defaults

Installer adds a managed .gitignore block that typically ignores:

• .agent-layer/ (except if teams choose to commit it)
• generated client config files/directories (for example .agents/, .agy/, .antigravitycli/, .claude/, .mcp.json, .codex/, .copilot/, .grok/, .grok-config/, .vscode/mcp.json, .vscode/settings.json, and .github/copilot-instructions.md)

Keep .agy/antigravity-cli/settings.json gitignored, but do not treat it as disposable: it is shared state and can contain native Antigravity settings such as workspace approval or trust. Agent Layer-managed MCP output remains safe to regenerate.

If you choose to commit .agent-layer/, keep .agent-layer/.gitignore so repo-local launchers, template copies, and backups stay untracked.

To commit .agent-layer/, remove the /.agent-layer/ line in .agent-layer/gitignore.block and re-run al sync.

To customize the managed block, edit .agent-layer/gitignore.block and re-run al sync.

.agent-layer/.env is ignored by .agent-layer/.gitignore, not the parent repo .gitignore.

docs/agent-layer/ is created when the wizard seeds Rules and memory; teams may choose to commit it or ignore it.

---

Design goals

• Make installation and day-to-day usage trivial
• Provide consistent core features across clients (instructions, skills, config generation, MCP servers, sync-on-run)
• Reduce moving parts by shipping a single global CLI and keeping .agent-layer/ config-first with minimal repo-local launchers

Changelog

See CHANGELOG.md for release history.

Contributing

Contributions are welcome. Please use the project's issue tracker and pull requests.

Contributor workflows live in docs/DEVELOPMENT.md.

License

See LICENSE.md.

Attributions

• Nicholas Conn, PhD - Conn Castle Studios