0e8a7b1734
* feat(desktop): add macOS app icon Replace the default electron-vite scaffold icon with the Multica asterisk icon. Adds build/icon.icns so electron-builder picks it up automatically via the `buildResources: build` config — no YAML change needed. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(desktop): run electron-vite build inside package script The package wrapper only ran bundle-cli.mjs and electron-builder, so electron-builder silently packaged whatever was already in out/. On a fresh checkout (or after a partial build) this shipped an app with a missing renderer bundle, which white-screens on launch. Add an explicit `electron-vite build` step between bundle-cli and electron-builder so `pnpm package` is self-contained. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(desktop): restore shell PATH in main process for GUI launches macOS/Linux GUI launches inherit a minimal PATH from launchd that omits ~/.zshrc, Homebrew, nvm, ~/.local/bin, and other shell config. Child processes spawned from the main process — including the bundled multica CLI used by daemon-manager — inherit the same stripped PATH, so the CLI fails to locate agent binaries like claude, codex, opencode, etc. with "no agent CLI found: … ensure it is on PATH". Use `fix-path` to recover the real shell PATH at startup, then prepend common install locations (/opt/homebrew/bin, /usr/local/bin, ~/.local/bin) as a fallback for broken shell rc or non-interactive $SHELL. Runs before setupDaemonManager so every subsequent spawn sees the corrected PATH. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(desktop): show onboarding wizard when authed user has no workspace Desktop is a single-shell architecture — every route, including /onboarding, lives inside DashboardGuard. The guard returns its loading fallback whenever workspace is null, so a fresh account that logs in with no workspaces ends up stuck on the spinner forever: the `replace(onboardingPath)` redirect navigates the tab router, but DashboardGuard still blocks its children because workspace is still null. Handle the empty-workspace case in DesktopShell itself: render OnboardingWizard as a full-screen takeover, bypassing DashboardGuard. A ref-based flag freezes the "needs onboarding" decision at first mount so creating a workspace mid-wizard (step 0) doesn't unmount the wizard and dump the user into the main shell before steps 1-3 (runtime, agent, get started) finish. Also add a local `bootstrapping` flag in AppContent so DesktopShell doesn't mount until the deep-link login chain (loginWithToken → syncToken → listWorkspaces → hydrateWorkspace) fully resolves. Without it, the shell would briefly see `!workspace` before hydration lands, causing users with existing workspaces to flash the wizard (or, with the ref freeze, get stuck in it permanently). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor(desktop): extract OnboardingGate with test coverage Pull the "render onboarding wizard when authed user has no workspace" logic out of DesktopShell into a dedicated OnboardingGate component. Replaces the ref-based freeze with a lazy useState initializer (`useState(() => !hasWorkspace)`), which is React's idiomatic pattern for "capture a value once at mount". The freeze semantics are unchanged: creating a workspace in step 0 of the wizard must not unmount it, because steps 1-3 still need to run; only `onComplete` flips the gate back to the main shell. Also de-duplicates the wrapping DesktopNavigationProvider — both branches of the shell now share a single provider instead of re-mounting one per branch. Wire up jsdom + @testing-library/react in the desktop vitest config (mirroring packages/views) and add three deterministic tests covering: 1. children render when hasWorkspace is true at mount 2. wizard stays mounted when hasWorkspace flips to true mid-flow 3. onComplete transitions the gate to children Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor(desktop): drop redundant syncToken call in deep-link login daemonAPI.syncToken was called twice on a deep-link login: once inside the deep-link handler's bootstrapping chain, and again in the useEffect([user]) that reacts to the user state change. Both calls spawn a multica CLI subprocess over IPC, wasting ~1-2s of startup time on the critical login path. Keep the [user] effect (it covers the session-restore path too) and drop the explicit call from the deep-link handler. Net effect: login latency shrinks, behavior is unchanged. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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 · 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, OpenClaw, and OpenCode.
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.
- Autonomous Execution — set it and forget it. Full task lifecycle management (enqueue, claim, start, complete/fail) with real-time progress streaming via WebSocket.
- 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-hostRequires Docker. See the Self-Hosting Guide for details.
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, openclaw, opencode) 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, OpenClaw, or OpenCode). 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.
Multica vs Paperclip
| Multica | Paperclip | |
|---|---|---|
| Focus | Team AI agent collaboration platform | Solo AI agent company simulator |
| User model | Multi-user teams with roles & permissions | Single board operator |
| Agent interaction | Issues + Chat conversations | Issues + Heartbeat |
| Deployment | Cloud-first | Local-first |
| Management depth | Lightweight (Issues / Projects / Labels) | Heavy governance (Org chart / Approvals / Budgets) |
| Extensibility | Skills system | Skills + Plugin system |
TL;DR — Multica is built for teams that want to collaborate with AI agents on real projects together.
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 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/Codex/ │
│OpenClaw/Code │
└──────────────┘
| 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, OpenClaw, or OpenCode |
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.