Summary

Archon derives codebase identity from the remote URL (owner/repo). When a user has multiple local clones of the same remote — for example a production-patches checkout and a development checkout — registerRepoAtPath returns the same codebase_id for both because findCodebaseByName matches on the remote-derived name.

This makes it impossible to:

• Register both clones as separate projects in the Web UI or via /register-project
• Have per-project env vars, commands, or workflow configurations scoped to each clone
• Run workflows from different clones without them sharing isolation environments, conversations, and session state

Root Cause

registerRepoAtPath() in packages/core/src/handlers/clone.ts:40-160:

1. Line 63: codebaseDb.findCodebaseByName(name) — queries remote_agent_codebases WHERE name = $1
2. When a record with that name exists (regardless of which local path created it), the existing record's id is returned
3. default_cwd is only updated if the new path is local and the existing one is archon-managed (lines 70-78)
4. For local-only repos (no remote), the name falls back to the directory basename — two directories with the same basename also collide

The codebases table uses name as the uniqueness key, not the local filesystem path.

Use Case

A developer has:

• ~/production/myapp — checked out at the latest release tag, used for hotfixes
• ~/development/myapp — on the dev branch, used for feature work

Both point to git@github.com:org/myapp.git. The developer wants to:

1. Register both in Archon with separate configurations (different env vars, different base branches)
2. Run workflows from each directory independently
3. Have conversations and sessions scoped to each checkout

Currently, registering the second clone silently reuses the first clone's codebase_id, merging all state.

Suggested Approach

The codebase identity should incorporate the local filesystem path, not just the remote URL. Options:

Option A: Composite uniqueness key — Change the codebases table uniqueness constraint from name alone to (name, default_cwd). This allows two registrations of org/myapp with different local paths. Display names could use org/myapp (production) and org/myapp (development).

Option B: Path-qualified name — When a name collision is detected and the paths differ, auto-suffix the name: org/myapp and org/myapp~development. The first registration keeps the clean name.

Option C: Explicit alias — Allow users to provide a custom name/alias at registration time that overrides the remote-derived name. The Web UI and /register-project would accept an optional name parameter.

Option A is the most correct but requires a schema migration. Option C is the least invasive.

Impact

• All platforms (CLI, Web, Slack, Telegram, GitHub)
• All features that scope by codebase_id (conversations, sessions, isolation environments, env vars, commands)
• Workaround: none — the second clone cannot be registered separately

Related

• Worktree reuse matches environments from different local clones of the same remote #1183 — worktree reuse across clones (DB-level guard, fixed in fix: prevent worktree reuse across different local clones #1186)
• Git-level worktree adoption bypasses cross-checkout guard and allows parallel collision #1188 — git-level worktree adoption bypass (filesystem-level, still open)
• fix: prevent worktree reuse across different local clones #1186 — cross-checkout guard PR (mitigates but doesn't solve the registration issue)

🤖 Generated with Claude Code