Technical Briefing: multica

The Problem

Multica addresses the fragmentation of working across multiple AI coding agents. Teams using Claude Code, Codex, Cursor, and other agent CLIs face context loss between sessions, redundant re-explanations, and disconnected execution logs. Each agent operates in isolation, requiring manual coordination to maintain continuity between issue assignment and pull request delivery.

What This Does

Multica is a self-hostable workspace that consolidates 20+ agent CLIs as teammates on a shared board. The repository comprises 5 self-contained projects: server (2,198 files, 2,159 code files), packages (1,633 files, 1,501 code files), apps (885 files, 567 code files), e2e (16 files), and scripts (22 files). The apps layer includes desktop (React + Electron), mobile, and web interfaces built with TypeScript/TSX, Tailwind, and Next.js. Core routing flows through the apps directory with entry points at apps/desktop/src/main/index.ts and apps/desktop/src/renderer/src/App.tsx. The server component (Go-heavy at 1,342 files) handles the daemon runtime and issue-agent assignment pipeline. Skills and squads features allow problem playbooks and team composition, while execution logs replay every tool call, command, and error timestamped to the associated issue.

How It Is Wired

Control flows from issue assignment through the daemon runtime, where an agent picks up work on a runtime controlled by the host. The agent's tool calls, commands, and errors are logged to the associated issue's execution log, creating a connected record of the run. The desktop app (apps/desktop/package.json, apps/desktop/electron-builder.yml) orchestrates the UI, while the server manages agent state and issue routing. Three high-severity findings relate to credential handling: apps/desktop/.env.staging is tracked despite .gitignore excluding it, and apps/mobile/.env.production and apps/mobile/.env.staging are committed with live credentials. Three GitHub Actions remain unpinned to commit SHAs (dorny/paths-filter@v3, pnpm/action-setup@v4, azure/setup-helm@v4, goreleaser/goreleaser-action@v6), meaning secrets available to the runner can change without pinning. The Dockerfile uses mutable base images (golang:1.26-alpine, alpine:3.21) without digest pins, and the GITHUB_TOKEN in mobile-verify.yml declares no permissions, inheriting repository defaults.

How To Use It

Setup: Clone with git clone https://github.com/moses-y/multica. Install dependencies via pnpm install (package manager inferred from lockfile and package.json files across apps and packages). Build the desktop app with pnpm -C apps/desktop build or start development with pnpm -C apps/desktop dev.

Configuration: Required environment variables are defined in .env.example at the root. Copy to .env and populate agent provider keys (Anthropic, OpenAI, etc.). The desktop app loads apps/desktop/.env.staging at runtime; this file is tracked and should be git-ignored and rotated. Mobile configuration lives in apps/mobile/package.json.

Running it: Start the development server with pnpm -C apps/desktop dev or launch the production build from apps/desktop/build. The server daemon starts via the Go entry point; consult VISION.md and SELF_HOSTING.md for production deployment steps, Docker builds using the provided Dockerfile, and domain/SSL configuration.

Real-World Use

A team assigns issue #47 to "Cursor" agent via the Multica board. Cursor picks up the issue, works within the host's runtime, and logs every tool call and command timestamped to #47. The human teammate monitors the execution log, sees intermediate results and blockers, and can intervene without re-explaining context. When Cursor finishes, it opens a pull request linked to the issue. The human reviews the diff, merges if acceptable, and the run is archived with token usage metrics. If the agent hits a blocker, it comments on the issue; the human assigns it to a different agent or re-scopes the work. All of this stays connected to the same issue—no reconstruction of context needed across sessions.

Code Health & Issues

The static analysis found the following:

  • HIGH - Untrack the file your own .gitignore says to ignore - apps/desktop/.env.staging (tracked although .gitignore excludes it; credentials in it are the ones actually in use)
  • HIGH - Pin third-party GitHub Actions to a commit SHA - .github/workflows (dorny/paths-filter@v3, pnpm/action-setup@v4, azure/setup-helm@v4, goreleaser/goreleaser-action@v6)
  • HIGH - Remove the committed .env and rotate what it holds - apps/desktop/.env.staging, apps/mobile/.env.production, apps/mobile/.env.staging (tracked .env is the most common route for working keys to reach a public clone)
  • MEDIUM - Declare least-privilege permissions for GITHUB_TOKEN - .github/workflows/mobile-verify.yml (no declaration; token inherits repository default)
  • MEDIUM - Enable Dependabot or Renovate (11 manifests, no update bot configured)
  • MEDIUM - Pin the container base image by digest - Dockerfile (golang:1.26-alpine, alpine:3.21)
  • MEDIUM - Add a pre-commit secret gate (no repo-level gate; secret-shaped file tracked)
  • MEDIUM - Set persist-credentials: false on checkout - .github/workflows/ci.yml (checkout keeps the token for later steps)
  • MEDIUM - Add a non-root USER to the image - Dockerfile (no USER directive; process runs as root)
  • LOW - Set timeout-minutes on the workflow jobs - .github/workflows/ci.yml (4 jobs declare no timeout, risking overlap behind two-hourly schedule)

Beyond these measured findings, the repository hygiene confirms committed secrets (apps/desktop/.env.staging, apps/mobile/.env.production, apps/mobile/.env.staging), a present license and lockfile, GitHub Actions CI, and Dockerfiles. The measured analysis also confirms this repo is a collection of 5 self-contained projects rather than a single codebase.

The Bottom Line

Multica delivers a practical workspace for teams running multiple AI coder agents, with solid separation between the Go server, TypeScript apps, and packages. The agent-board model, execution logging, and skills/squads features are the strongest value points. However, three high-severity credential leaks (tracked .env files), unpinned GitHub Actions, and mutable Docker base images are urgent to address before self-hosting in a shared environment. Teams comfortable with self-hosting and willing to rotate committed secrets and pin dependencies will find it functional; others should wait for a patched release or use the hosted offering until these hygiene items are resolved.