b933d9fd41
* feat(composio): server-side connect flow + connections REST (Notion MVP) (MUL-3720) Compose the merged server/pkg/composio SDK into a user-facing connection manager: signed-state connect handshake, local user_composio_connection mirror, idempotent disconnect, and a per-user MCP session helper (not yet wired into task dispatch). - migration 127_user_composio_connection (no FK/cascade, per DB rules) - sqlc queries: upsert (idempotent on user_id+connected_account_id), list active, owner-scoped get, mark revoked - internal/integrations/composio: signed HMAC-SHA256 state, BeginConnect, CompleteCallback (idempotent upsert), ListConnections, Disconnect (upstream 404 = idempotent success), CreateMCPSession (no-op when empty, pins connected_accounts per toolkit), CallbackRedirect - REST handlers under /api/integrations/composio (user-scoped, 503 when COMPOSIO_API_KEY unset): connect/init, callback (302), connections list, delete - router wiring gated by COMPOSIO_API_KEY; COMPOSIO_AUTH_CONFIGS_JSON maps toolkit->auth_config (MVP: notion); state secret from COMPOSIO_STATE_SECRET or derived from JWT_SECRET; callback base from COMPOSIO_CALLBACK_BASE_URL or MULTICA_PUBLIC_URL - tests: state (expire/tamper/wrong-secret), service (mapping, callback idempotency, non-success, disconnect owner/404 idempotency, MCP pin), handlers (httptest), redact regression for Bearer mcp_ tokens MVP scope: Notion only; no task-dispatch overlay, sharing, or webhook event handling (later stages). Co-authored-by: multica-agent <github@multica.ai> * fix(composio): bind callback account to user + idempotent revoked disconnect (MUL-3720) Address PR 4608 review (CHANGES_REQUESTED): - callback: verify connected_account_id with Composio before mirroring it. The signed state only proved user/toolkit/exp, so a valid state paired with a tampered connected_account_id would be written verbatim. CompleteCallback now calls ListConnectedAccounts and fails closed (ErrAccountVerification) unless the account belongs to the state's user (composio_user_id == multica user id) and was created under the toolkit's auth config. No row is written on mismatch / unknown account / upstream error. - disconnect: short-circuit to a no-op when the local row is already revoked, before touching upstream. Previously a second DELETE re-hit Composio and a non-404 upstream error surfaced as a 502, breaking the 204-idempotent contract. - CreateMCPSession: document the v1 single-active-connection-per-(user,toolkit) constraint and make duplicate selection deterministic (newest-wins, rows are connected_at DESC) instead of order-dependent map overwrite. Stage 3 owns the real single-account-enforcement vs multi-account-shape decision. Tests: tampered/wrong-auth-config/unknown-account callback rejection, revoked-row disconnect no-op (asserts upstream not re-hit). composio pkg 85% coverage; all green. Co-authored-by: multica-agent <github@multica.ai> * feat(composio): list all toolkits + dynamic auth-config resolution (MUL-3720) Yushen's follow-up to the Notion MVP: surface the full Composio toolkit catalog, render it in Settings, and drop the static env mapping in favor of dynamic auth-config discovery. Config correctness (per Composio docs): - Remove COMPOSIO_AUTH_CONFIGS_JSON entirely. The toolkit→auth_config mapping is now resolved at request time from the project's /auth_configs (cached, 5-min TTL), so enabling a toolkit is a dashboard action, not a redeploy. - Do NOT add COMPOSIO_PROJECT_ID. The project API key (x-api-key) authenticates to exactly one project; the project is resolved from the key. Only org-level endpoints use x-org-api-key, which this integration never calls. Backend: - SDK: server/pkg/composio/auth_configs.go — ListAuthConfigs (toolkit_slug, is_composio_managed, show_disabled, limit, cursor). - service: dynamic resolver (authConfigMap cache; betterAuthConfig prefers a custom/white-label config over Composio-managed, newest wins); BeginConnect and CompleteCallback resolve via it; ListToolkits fetches the full catalog (paginated, capped) annotated with connectable = has an enabled auth config, connectable-first ordering. - handler + route: GET /api/integrations/composio/toolkits (user-scoped, 503 when COMPOSIO_API_KEY unset) returning slug/name/logo/category/connectable. Frontend: - core: ComposioToolkit/ComposioConnection types, api client methods, and composio query options (@multica/core/composio). - views: Settings → Integrations now has a Composio section rendering every toolkit as a card with search. Connect is gated on `connectable`; non-connectable toolkits show a muted "not configured" hint instead of a dead button. Connected toolkits show a badge + Disconnect (with confirm). - i18n: composio block added to en/zh-Hans/ja/ko settings. Tests: SDK + service (dynamic resolution, custom-over-managed preference, connectable flag, resolver-error soft-degrade) and handler toolkits endpoint; composio pkg 85.7% coverage. go build/vet/gofmt clean; core+views typecheck, core+views lint, and core tests (691) all green. Co-authored-by: multica-agent <github@multica.ai> * fix(composio): close cross-toolkit callback fail-open by signing auth_config_id into state (MUL-3720) Re-review blocker: CompleteCallback resolved the toolkit's auth config at callback time and ignored a resolve error/empty result, while verifyAccountOwnership skipped the auth-config comparison when the expected value was empty. A user could then pass another toolkit's connected_account_id into this toolkit's callback — the owner check passed and it was written under the wrong toolkit_slug/account binding. Fix: the auth_config_id is already resolved in BeginConnect (before the state is signed), so sign it into the state and compare it exactly at callback. No re-resolve, no fail-open. verifyAccountOwnership now fails closed when the expected auth config is empty (rejects instead of skipping) and requires an exact match — closing the cross-toolkit binding gap. Tests: state round-trips auth_config_id; BeginConnect signs it; callback rejects wrong/cross-toolkit auth config and an empty (no-mapping) auth config fails closed. composio pkg 85.2% coverage, all green. Frontend (non-blocking): the Composio settings tab now surfaces an error when the connections query fails instead of silently rendering everything as unconnected. Co-authored-by: multica-agent <github@multica.ai> * fix(composio): hide Settings section entirely when integration unconfigured (MUL-3720) Decision (option 2, hide-then-merge): don't show a card that leaks the internal COMPOSIO_API_KEY env-var name to every end user. IntegrationsTab now gates the whole Composio section (heading + body) on the toolkits query — a 503 means the key is unset, so the section is withheld instead of rendering the not-configured card. Admin-only setup guidance is a later, role-gated affordance. Removed the notConfigured card (and now-unused ApiError import) from ComposioTab; it only mounts when configured. views typecheck + lint clean. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>
Multica
Your next 10 hires won't be human.
The open-source managed agents platform.
Turn coding agents into real teammates — assign tasks, track progress, compound skills.
Website · Cloud · Discord · X · Self-Hosting · Contributing
English | 简体中文
What is Multica?
Multica turns coding agents into real teammates. Assign issues to an agent like you'd assign to a colleague — they'll pick up the work, write code, report blockers, and update statuses autonomously.
No more copy-pasting prompts. No more babysitting runs. Your agents show up on the board, participate in conversations, and compound reusable skills over time. Think of it as open-source infrastructure for managed agents — vendor-neutral, self-hosted, and designed for human + AI teams. Works with Claude Code, Codex, GitHub Copilot CLI, OpenClaw, OpenCode, Hermes, Gemini, Pi, Cursor Agent, Kimi, Kiro CLI, and Qoder CLI.
For larger teams, Squads add a stable routing layer: assign work to a group led by an agent, and the leader delegates to the right member.
Why "Multica"?
Multica — Multiplexed Information and Computing Agent.
The name is a nod to Multics, the pioneering operating system of the 1960s that introduced time-sharing — letting multiple users share a single machine as if each had it to themselves. Unix was born as a deliberate simplification of Multics: one user, one task, one elegant philosophy.
We think the same inflection is happening again. For decades, software teams have been single-threaded — one engineer, one task, one context switch at a time. AI agents change that equation. Multica brings time-sharing back, but for an era where the "users" multiplexing the system are both humans and autonomous agents.
In Multica, agents are first-class teammates. They get assigned issues, report progress, raise blockers, and ship code — just like their human colleagues. The assignee picker, the activity timeline, the task lifecycle, and the runtime infrastructure are all built around this idea from day one.
Like Multics before it, the bet is on multiplexing: a small team shouldn't feel small. With the right system, two engineers and a fleet of agents can move like twenty.
Features
Multica manages the full agent lifecycle: from task assignment to execution monitoring to skill reuse.
- Agents as Teammates — assign to an agent like you'd assign to a colleague. They have profiles, show up on the board, post comments, create issues, and report blockers proactively.
- Squads — group agents (and humans) under a leader agent and assign work to the squad. The leader decides who should pick it up, so routing stays stable as the team grows.
@FrontendTeaminstead of@alice-or-bob-or-carol. - Autonomous Execution — set it and forget it. Full task lifecycle management (enqueue, claim, start, complete/fail) with real-time progress streaming via WebSocket.
- Autopilots — schedule recurring work for agents. Cron triggers, webhooks, or manual runs — each autopilot creates the issue and routes it to an agent automatically, so daily standups, weekly reports, and periodic audits run themselves.
- Reusable Skills — every solution becomes a reusable skill for the whole team. Deployments, migrations, code reviews — skills compound your team's capabilities over time.
- Unified Runtimes — one dashboard for all your compute. Local daemons and cloud runtimes, auto-detection of available CLIs, real-time monitoring.
- Multi-Workspace — organize work across teams with workspace-level isolation. Each workspace has its own agents, issues, and settings.
Quick Install
macOS / Linux (Homebrew - recommended)
brew install multica-ai/tap/multica
Use brew upgrade multica-ai/tap/multica to keep the CLI current.
macOS / Linux (install script)
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash
Use this if Homebrew is not available. The script installs the Multica CLI on macOS and Linux by using Homebrew when it is on PATH, otherwise it downloads the binary directly.
Windows (PowerShell)
irm https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.ps1 | iex
Then configure, authenticate, and start the daemon in one command:
multica setup # Connect to Multica Cloud, log in, start daemon
Self-hosting? Add
--with-serverto deploy a full Multica server on your machine:curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server multica setup self-hostThis pulls the official Multica images from GHCR (latest stable by default). Requires Docker. See the Self-Hosting Guide for details. If the selected GHCR tag has not been published yet, fall back to
make selfhost-buildfrom a checkout.
Getting Started
1. Set up and start the daemon
multica setup # Configure, authenticate, and start the daemon
The daemon runs in the background and auto-detects agent CLIs (claude, codex, copilot, openclaw, opencode, hermes, gemini, pi, cursor-agent, kimi, kiro-cli, agy, qodercli) on your PATH.
2. Verify your runtime
Open your workspace in the Multica web app. Navigate to Settings → Runtimes — you should see your machine listed as an active Runtime.
What is a Runtime? A Runtime is a compute environment that can execute agent tasks. It can be your local machine (via the daemon) or a cloud instance. Each runtime reports which agent CLIs are available, so Multica knows where to route work.
3. Create an agent
Go to Settings → Agents and click New Agent. Pick the runtime you just connected and choose a provider (Claude Code, Codex, GitHub Copilot CLI, OpenClaw, OpenCode, Hermes, Gemini, Pi, Cursor Agent, Kimi, Kiro CLI, Antigravity, or Qoder CLI). Give your agent a name — this is how it will appear on the board, in comments, and in assignments.
4. Assign your first task
Create an issue from the board (or via multica issue create), then assign it to your new agent. The agent will automatically pick up the task, execute it on your runtime, and report progress — just like a human teammate.
CLI
The multica CLI connects your local machine to Multica — authenticate, manage workspaces, and run the agent daemon.
| Command | Description |
|---|---|
multica login |
Authenticate (opens browser) |
multica daemon start |
Start the local agent runtime |
multica daemon status |
Check daemon status |
multica setup |
One-command setup for Multica Cloud (configure + login + start daemon) |
multica setup self-host |
Same, but for self-hosted deployments |
multica workspace list |
List your workspaces (current is marked with *) |
multica workspace switch <id|slug> |
Switch the default workspace for this profile |
multica issue list |
List issues in your workspace |
multica issue create |
Create a new issue |
multica update |
Update to the latest version |
See the CLI and Daemon Guide for the full command reference.
Architecture
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Next.js │────>│ Go Backend │────>│ PostgreSQL │
│ Frontend │<────│ (Chi + WS) │<────│ (pgvector) │
└──────────────┘ └──────┬───────┘ └──────────────────┘
│
┌──────┴───────┐
│ Agent Daemon │ runs on your machine
└──────────────┘ (Claude Code, Codex, GitHub Copilot CLI,
OpenCode, OpenClaw, Hermes, Gemini,
Pi, Cursor Agent, Kimi, Kiro CLI, Qoder CLI)
| Layer | Stack |
|---|---|
| Frontend | Next.js 16 (App Router) |
| Backend | Go (Chi router, sqlc, gorilla/websocket) |
| Database | PostgreSQL 17 with pgvector |
| Agent Runtime | Local daemon executing Claude Code, Codex, GitHub Copilot CLI, OpenClaw, OpenCode, Hermes, Gemini, Pi, Cursor Agent, Kimi, Kiro CLI, or Qoder CLI |
Development
For contributors working on the Multica codebase, see the Contributing Guide.
Prerequisites: Node.js v20+, pnpm v10.28+, Go v1.26+, Docker
make dev
make dev auto-detects your environment (main checkout or worktree), creates the env file, installs dependencies, sets up the database, runs migrations, and starts all services.
See CONTRIBUTING.md for the full development workflow, worktree support, testing, and troubleshooting.
An iOS mobile client lives in apps/mobile/ — see its README for how to build it onto your own iPhone.