Project registration falls back to Claude instead of configured Pi provider

[b1skit]

Summary

• What broke: Project registration can store claude as the project AI provider even when the intended/default provider is pi. The orchestrator then injects AI Provider: claude into the project context, causing the chat agent to believe Claude is configured for the project.
• When it started (if known): Unknown.
• Severity: major

Steps to Reproduce

1. Configure Archon so the intended/default assistant provider is pi.
2. Register or clone a project that does not contain .codex/ or .claude/ provider-specific directories.
3. Open the project in the Web chat and ask the agent to inspect or audit the project configuration.
4. Observe that the orchestrator prompt/project context reports AI Provider: claude.

Expected vs Actual

• Expected: A project registered in a Pi-configured Archon instance should be registered with ai_assistant_type = pi, or project registration should explicitly ask/select a provider instead of silently falling back to Claude.
• Actual: The project is registered with ai_assistant_type = claude. The orchestrator prompt includes AI Provider: claude, and the chat agent treats that as authoritative project configuration.

User Flow

  User                   Archon                   AI Client
  ────                   ──────                   ─────────
  configures Pi ───────▶ DEFAULT_AI_ASSISTANT=pi
  registers project ───▶ detects no .codex/.claude folder
                         falls back to first built-in provider
                         stores ai_assistant_type=claude [X]
  opens Web chat ──────▶ builds orchestrator prompt
                         injects "AI Provider: claude"
                         sends prompt ───────────▶ believes project uses Claude
  asks config question ◀────────────────────────── says Claude is configured

Environment

• Platform: Web
• Database: SQLite / PostgreSQL
• Running in worktree? No
• OS: Linux / Docker

Logs

Example visible symptom from chat output:

Configuration Assessment
The project is registered in Archon with:

Directory: <project path>
AI Provider: claude

When challenged, the agent attributed this to the Registered Projects section of its prompt rather than anything found in the repository.

Impact

• Affected workflows/commands: Project registration, clone/register flow, Web chat orchestration, any workflow selection or routing that relies on remote_agent_codebases.ai_assistant_type.
• Reproduction rate: Always, when a project is registered without .codex/ or .claude/ and the intended provider is Pi.
• Workaround available? Manually update the project row in remote_agent_codebases.ai_assistant_type to pi, then reset/recreate affected conversations/sessions so stale provider state is not reused.
• Data loss risk? No

Scope

• Package(s) likely involved: core|server|web
• Module (if known): core:handlers/clone, core:db/codebases, core:orchestrator/prompt-builder, providers:registry

[m13v]

this is the silent-default-on-detect-miss pattern. the bug isn't really 'falls back to claude', it's that detection returns a value when it should return null. anywhere you infer config from filesystem signals (.codex/, .claude/, autofill rows, history hosts) the function needs three states: detected, absent, ambiguous. collapsing absent into 'first item in registry' looks fine until DEFAULT_AI_ASSISTANT disagrees with the registry order, then the env var quietly stops mattering. fix is usually: detect returns Optional[Provider], registration explicitly resolves Optional -> env-default -> prompt, and the orchestrator prompt logs which lane resolved it so the chat surface can tell the user 'pi (from env)' vs 'claude (from .claude/)'. otherwise every reproduction looks like state corruption.