Questions,
answered.

The CLI analyzes edits on your machine and sends metadata: paths, symbol names, signature hashes, compatibility, references to contracts, and (in the default full data mode) normalized signature text. It never sends file contents or diffs. With the optional GitHub App in full mode, Comity reads changed files of pushed branches from GitHub to analyze them in memory. See Security & data.

The hook before an edit waits at most 400 ms for Comity's answer once connected, plus the time it took to connect (at most 800 ms in all), typically far less; after that it lets the edit through and tells you once per session that the check was skipped. Other events wait up to 1.5 s. Reads and searches never call Comity.

Agents carry on without coordination; each skipped check is logged locally in hook.log. Comity never blocks an agent because it is unavailable.

Rarely, by design. With default settings, only edits to protected paths block (and only if you configure some). Exclusive claims, require_intent: required, and contract breaks on high-criticality contracts can block too. Everything else warns. A blocked agent is told why and should coordinate; a human can override in the dashboard.

No. Hooks report what agents actually edit, and the first prompt auto-drafts an intent. Declaring one with intent_declare adds scope (paths, symbols, contracts), so teammates are warned before anyone edits. You can require it with the require_intent policy.

Yes, if they work in different checkouts (worktrees) or branches. An agent and its subagents, or two sessions in the same checkout and branch, are one lineage and never conflict: to run two independent tasks in parallel, start each agent in its own worktree (git worktree add ../<repo>-2 -b agent-2; see One checkout per agent). Conflicts between one developer's own agents don't count toward time saved, and info-level file overlaps between them wait for the next prompt and come as one FYI line that needs no ack (see Conflicts).

Yes, with shared tasks. Tell each agent to work from the file ("build SPEC.md"): Comity turns its checkboxes or sections into tasks and each agent claims a different one, one at a time. A task becomes done when its work lands. Handing tasks to a teammate's agent always needs that teammate's yes, in their agent's approval prompt or the dashboard.

At the recipient agent's next edit or shell command (mid-task), when a Claude Code subagent it was waiting on returns, or at its next prompt, whichever comes first. An agent waiting for a reply with inbox and wait_seconds gets it as soon as it is sent.

Yes. user:<email> reaches the person in the dashboard and their agents. People post in the dashboard's Messages tab; their posts reach agents the same way.

Yes, with Ask my agent (paid plans, off by default): a read-only copy of your most recent agent session answers their questions on your machine while your agent is busy or away. It never edits code or runs commands; requests to change something wait for your agent. Turn it on with comity ask-my-agent on or in Settings → Autopilot → Ask my agent.

Yes, with Autopilot (paid plans, off by default): trusted teammates' work requests are accepted without asking you, and your open Claude Code, Codex or omp session does the work, waiting for the next task in between with no model running. Turn it on with comity autopilot on, /autopilot in your agent or Settings → Autopilot; the first time you type yes to a warning. When you're back, the agent tells you what it did.

Claude Code and Codex (set up by default), plus Cursor, GitHub Copilot, Gemini CLI, Windsurf, Kiro, Cline, OpenCode, Amp, Factory Droid, goose, Junie, Augment and omp with hooks, and Roo Code, Zed and Continue over MCP with an instructions file: comity init --tools <id> or --tools all. Any other MCP client can use the tools without hooks. See Supported agents.

Paths work for every file. Symbols and signatures: TypeScript, TSX, JavaScript, Python (including dataclass/pydantic/TypedDict fields) and Go (including calls between packages of a Go module). HTTP routes and calls: TypeScript/JavaScript, Python and Go. Zod schemas: TypeScript/JavaScript. Database tables and numbered migrations: SQL files, Prisma schemas, Knex migrations and Drizzle tables.

Yes, for HTTP routes and workspace packages: a breaking change in one repo is reported to agents in other repos that call the route or import the package. Controlled by cross_repo_contracts and projects.

Yes. Workspace packages (npm, pnpm and yarn workspaces, Python packages, tsconfig paths) are discovered at session start, and briefings note which package a path belongs to. Claude Code and omp load the repo's hooks only when started at the repo root; to start them in a package folder, run comity init --global once. See Monorepos.

Delete the Comity entries from .claude/settings.json, .mcp.json, .codex/hooks.json and .codex/config.toml (and .omp/extensions/comity/ and .omp/mcp.json for omp), and commit. On a machine, comity logout removes the stored token and revokes it on the server; npm uninstall -g comity-cli removes the CLI.

A member whose agents used Comity this month. Viewers, billing contacts and service tokens are free. See Billing & plans.

Nothing breaks. Developers beyond the 5th in a month run uncoordinated (with a notice) until you upgrade or the month ends. See Plan limits.

For Enterprise pilots, yes; see Self-hosting.