Agent details

Disclaimer: These documents reflect our current understanding of each agent’s hook system and extensibility surface. They are maintained as working references for symposium development, not as a substitute for each project’s official documentation. Details may be outdated or incomplete — always consult the primary sources linked in each agent’s page.

For each agent it supports, symposium needs to know:

1. Hook registration — where and how to write config so the agent calls cargo-agents hook
2. Hook I/O protocol — event names, input/output field names, exit code semantics
3. Extension installation — where skill files go (project and global)
4. Custom instructions — where the agent reads project-level instructions

The tables below summarize the answers for each agent. Individual agent pages contain the full reference. A ? indicates information we have not yet documented.

Hook registration

Command field

Timeout defaults

Event names

Symposium registers hooks for four events. Each agent uses different names and casing conventions.

Blocking support

Not all events can block the action in all agents.

Hook I/O protocol

Input fields (pre-tool-use)

Output structure (pre-tool-use)

Exit codes

All shell-based agents use the same convention (where applicable):

Exceptions: Copilot uses exit 0 = allow, non-zero = deny (no special meaning for exit 2). OpenCode uses JS exceptions, not exit codes.

Extension installation

Skill file paths

Symposium uses the vendor-neutral .agents/skills/ path whenever the agent supports it, falling back to agent-specific paths (e.g., .claude/skills/, .kiro/skills/) when required. Codex CLI and OpenCode also support .agents/skills/ natively.

Custom instructions

MCP server configuration

Relevant if symposium exposes functionality via MCP.

An agent’s MCP file is usually not the file its hooks live in, and the per-agent entry shapes differ more than they look. Agent::mcp_config_path encodes this table; every row marked verified was confirmed by asking the tool (<tool> mcp list reporting an entry symposium wrote, and <tool> mcp add showing which file it chooses), because a wrong guess here fails silently - symposium reports success for a file the agent never reads.

Notes that cost real debugging time:

• Claude Code ignores mcpServers in settings.json at both scopes - that file is hooks only. See Claude Code.
• The Copilot CLI requires the mcpServers wrapper; entries written bare at the top level make it reject the whole file (mcpServers: Required), taking the user’s own servers down with it. .vscode/mcp.json belongs to the VS Code extension, a different product symposium does not currently target.
• OpenCode rejects the entire config file for a wrong entry shape, so its serializer is separate: the command is one array, and env vars go under environment (an env key parses but never reaches the child).
• Codex, Copilot CLI and Goose have no project-level MCP config, so project scope resolves to their user-level file rather than to a file nobody reads.
• Goose uses cmd, not command, and requires a type; the nested provider: mcp / config: form it once got is rejected outright. Remote is type: streamable_http with uri - Goose has no sse variant.
• env/headers must be maps. ACP models them as [{name, value}] pairs, and a list is skipped or rejected - silently, for an entry that differs from a working one only by carrying env. Codex takes env as a TOML table, Goose as envs, OpenCode as environment, everyone else as env.
• The Copilot CLI also needs an explicit type (local/http/sse), or a remote entry never appears.