6bbe059055
* fix(desktop): ship entitlements.mac.plist so electron-builder can codesign electron-builder.yml already references build/entitlements.mac.plist via entitlementsInherit, but the file was missing from the tree, so `pnpm package` failed at the codesign step with: build/entitlements.mac.plist: cannot read entitlement data Ship the file. It grants the hardened-runtime capabilities the app actually needs: JIT + unsigned executable memory for V8, disabled library validation so the Electron process can spawn the bundled `multica` Go binary as a child process, and network client/server for the daemon's API and /health endpoints. Also tweak the root .gitignore: the top-level `build` rule was shadowing apps/desktop/build/, hiding this config file from git. Add a scoped exception so apps/desktop/build/ (which holds electron-builder source resources, not output) is tracked. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(desktop): derive package version from git tag at build time The Desktop app version was hardcoded to "0.1.0" in package.json and never bumped, while the bundled CLI reports whatever `git describe` gives at build time. Result: packaging on main produced desktop-0.1.0.dmg containing multica v0.1.35-14-gf1415e96 — completely disconnected. Users see two unrelated version numbers for the same release. Sync them by using the same source GoReleaser uses for the CLI: the nearest git tag. A new scripts/package.mjs wrapper runs bundle-cli.mjs, derives the version via `git describe --tags --always --dirty` (strips the `v` prefix, falls back to `0.0.0-<hash>` when no tags are reachable), and invokes electron-builder with `-c.extraMetadata.version=<derived>` — which overrides package.json at build time without mutating the tracked file. On a clean tag commit → "0.1.36"; between tags → "0.1.35-14-gf1415e96" (valid semver prerelease); dirty tree → same with "-dirty" suffix. The `package` script in package.json now points to the wrapper. Passthrough args (--mac, --arm64, etc.) after `pnpm package --` are forwarded to electron-builder unchanged. Dev and build scripts are untouched — they continue to use bundle-cli.mjs directly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(desktop): enable macOS notarization and clean artifact names Two electron-builder.yml tweaks that unblock a proper release: - `mac.notarize: false` → `true`. Notarization runs in-build via notarytool, reading APPLE_ID/APPLE_APP_SPECIFIC_PASSWORD/APPLE_TEAM_ID from env. electron-builder then staples the ticket before zipping, so `latest-mac.yml`'s SHA512s match the published artifacts (critical for electron-updater — post-hoc re-stapling would invalidate them). Non-mac/CI contributors are unaffected: `pnpm package` already requires the Developer ID signing cert, and notarization is a strict superset of signing. - `mac.artifactName` and `dmg.artifactName` now hardcode `multica-desktop-${version}-${arch}.${ext}` instead of using `${name}`, which expands to `@multica/desktop` for scoped package names and literally produced files at `dist/@multica/desktop-*.dmg`. The nested `@multica/` path is useless and makes the GitHub Release asset URL ugly. New layout is flat: `dist/multica-desktop-<ver>-arm64.dmg`. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(desktop): keep local package builds working after notarize: true Three polish items from review of this PR. - Local dev regression: `mac.notarize: true` in electron-builder.yml made `pnpm package` hard-fail on macs without APPLE_* env vars, even for non-publishing local smoke tests. Detect the missing env in scripts/package.mjs and pass `-c.mac.notarize=false` for that run only. Real release builds (which source apps/desktop/macOS/.env via the release-desktop skill) are unaffected. Also logs a clear warning so the developer knows notarization was skipped. - spawnSync previously used `shell: true`, which reassembled argv into a shell command string. Zero real-world injection risk given our controlled inputs, but dropping it closes the vector at no cost — pnpm already puts node_modules/.bin on PATH for script runs so the binary is found without a shell wrapper. - On spawn failure (e.g. electron-builder not found), result.error was silently swallowed and the exit was just `1`. Log the underlying reason before exiting. Also refactor so normalizeGitVersion is exportable and guard the main entry behind an import.meta.url check, enabling unit coverage. New package.test.mjs covers the six branches: null/empty input, clean tag, between-tags prerelease, dirty suffix, v-prefixed prerelease tags (vX.Y.Z-alpha and vX.Y.Z-rc.2), and the 0.0.0-<hash> fallback for hash-only describe output. vitest.config.ts picks up scripts/**/*.test.mjs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(desktop): commit .env.production for release builds Bake production backend + app URLs into release packages so `pnpm package` produces a build that points at multica.ai out of the box. electron-vite (Vite) reads .env.production automatically in production mode — no script changes needed. Values: VITE_API_URL = https://api.multica.ai VITE_WS_URL = wss://api.multica.ai/ws VITE_APP_URL = https://multica.ai Also parameterize the two hardcoded `https://www.multica.ai` strings in platform/navigation.tsx's `getShareableUrl` on VITE_APP_URL. The previous hardcoded host pointed to `www.multica.ai`, which disagrees with the canonical `multica.ai` we're standardizing on. Shareable links from the desktop ("Copy link to issue") now match. The env file is public config, not a secret, so add a scoped exception to the root .gitignore's `.env*` rule. 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.