Spurious nested .fusion/.fusion/ directory created in every project and worktree

[timothyjlaurent]

Summary

Fusion recursively creates a .fusion/ directory inside its own .fusion/ directory, producing a spurious nested state directory at .fusion/.fusion/. This happens in every project and inside every worktree — 100% reproduction rate across all 10 worktrees tested.

The nested copy contains a separate, independent SQLite database with its own diverged config, 0 tasks, and nextId=1. When the Fusion TUI/daemon reads from the wrong copy, it shows an empty task board despite the real DB having 44 tasks.

Reproduction

1. Initialize Fusion in any project (npx runfusion.ai)
2. Observe that both .fusion/ and .fusion/.fusion/ are created
3. The nested copy has its own fusion.db, archive.db, WAL/SHM files, and config.json

Evidence

Directory structure

.fusion/                          ← real state (44 tasks, 13 MB DB)
.fusion/.fusion/                  ← spurious copy (0 tasks, 708 KB DB)
.fusion/.fusion/fusion.db
.fusion/.fusion/fusion.db-wal
.fusion/.fusion/fusion.db-shm
.fusion/.fusion/archive.db
.fusion/.fusion/config.json

Same pattern in every worktree:

.worktrees/fn-016/.fusion/        ← real worktree state
.worktrees/fn-016/.fusion/.fusion/ ← spurious nested copy
.worktrees/fn-037/.fusion/.fusion/ ← spurious nested copy
... (all 10 worktrees have this)

DB comparison

Property	.fusion/ (real)	.fusion/.fusion/ (spurious)
fusion.db size	13 MB	708 KB
Tasks	44	0
config.nextId	60	1
archived_tasks	9	0
Task folders	15+ (FN-001 through FN-053+)	0

Config drift

Setting	Real	Nested
maxConcurrent	4	2
maxWorktrees	20	4
worktreeNaming	"task-id"	"random"
specStalenessEnabled	true	false
memoryDreamsEnabled	true	false
experimentalFeatures	8 features enabled	{} (empty)
showQuickChatFAB	true	false

The nested config appears to be a default/older Fusion config. If the TUI ever reads from the wrong directory, it picks up stale settings.

Impact on running process

lsof on a running Fusion process shows it has both DBs open simultaneously:

node  16507  42u  REG  17.9 MB  .../fitness-app/.fusion/fusion.db          ← real (44 tasks)
node  16507  54u  REG  724 KB   .../fitness-app/.fusion/.fusion/fusion.db   ← spurious (0 tasks)

The TUI was displaying from the empty nested copy, showing no tasks.

Git tracking

The nested .fusion/.fusion/ is tracked in git — fusion.db, fusion.db-shm, and fusion.db-wal are committed to the repository. There is no .gitignore rule for .fusion/. SQLite databases and WAL files should never be committed to version control.

Environment

• Fusion version: 0.13.0 (via npx)
• Node.js: v24.15.0
• OS: macOS 15.3 (Darwin 24.3.0)
• Driver: node:sqlite (DatabaseSync)

Suggested fix

The directory detection logic in Fusion likely uses a glob or recursive scan that matches .fusion/ inside itself. The fix should:

1. Skip .fusion/ when scanning inside .fusion/ — the state directory should never be nested recursively.
2. Add .fusion/ to .gitignore automatically on init (or at least *.db, *.db-wal, *.db-shm).
3. Guard against opening the wrong DB — verify the opened DB has the expected nextId / task count before using it as the primary state.

Related

• Recurring SQLite B-tree corruption in fusion.db (agentLogEntries) #24 (recurring B-tree corruption on agentLogEntries) — the nested DB also gets its own corrupted copies and WAL files, compounding the disk waste and confusion.

[gsxdsm]

On this now and the db corruption fix

[gsxdsm]

This one was tricky! Think all paths are resolved - please check out 0.14.3