DevClaw can silently fork project registry state by creating an empty devclaw/projects.json

[fujiwaranosai850]

Summary

DevClaw startup/workspace scaffolding can silently create a fresh empty devclaw/projects.json when that file is missing.

If project registry state still exists in a legacy location, this creates a dangerous failure mode: DevClaw can appear to have "forgotten" all registered projects, not because state was truly deleted, but because startup minted a new empty canonical registry instead of failing loudly or forcing migration.

Why this matters

The project registry is the control-plane state for DevClaw. If it silently forks to an empty registry, users see symptoms like:

• projects seemingly disappearing after restart
• projects seemingly disappearing on new context/session loads
• channel routing no longer finding a project
• task/project tools behaving as if nothing is registered

Local downstream symptom

In local downstream investigation, the canonical registry path was:

• /home/sai/.openclaw/workspace/devclaw/projects.json

At the time of investigation it contained an empty registry:

{
  "projects": {}
}

That may not be the only root cause in the field, but it exposed a real silent failure mode in workspace startup behavior.

Fault line

Current workspace scaffolding behavior creates devclaw/projects.json if it is missing.

That is fine for a truly fresh workspace, but unsafe when any legacy registry still exists at paths like:

• projects.json
• projects/projects.json

In that case, startup should not quietly create a blank canonical registry.

Recommended fix

Before creating a fresh empty devclaw/projects.json, DevClaw should:

1. check for known legacy registry locations
2. fail loudly if a legacy registry exists
3. require migration / reconciliation instead of silently forking state

Status

I have a downstream local fix and regression tests for this guard.

I am holding the upstream PR until the rest of the root-cause trace is complete, in case there is an adjacent deeper fix worth including cleanly.

[fujiwaranosai850]

Clarification after downstream investigation: the core bug here should be described as a runtime project-registry persistence gap, not a PROJECT.md loading issue.\n\nWhat appears true downstream:\n\n- canonical runtime state is devclaw/projects.json\n- after restart and/or new context, DevClaw can effectively come up with an empty or missing project registry\n- when that happens, task/project tools behave as if no projects are registered\n- nearby PROJECT.md files are local/doc conventions, not the upstream runtime control plane\n\nSo the upstream gap to fix is around durable devclaw/projects.json preservation/recovery, workspace resolution, startup/setup behavior, and reliable project/channel registration continuity across restart/new context.