One project, however its path is spelled

[scgopi]

What was happening

Creating a child loop from inside a codespace added a second project to the sidebar — same name, empty graph — and the child loop went into it, where nothing was watching.

Why

Opening a project is create-if-missing. That is deliberate: graphcode status <folder> from a shell is how a folder gets added. But every path a client named went straight through it, and a loop names paths constantly — its own worktree, its working directory, its project path with a trailing slash.

A codespace turned that from possible into certain. A remote path cannot be checked against this filesystem, so unlike a local folder, every spelling of one was openable. Reproduced against a real daemon before the fix:

$ graphcode projects
repo @ demo-cs  codespace://demo-cs/workspaces//repo
repo @ demo-cs  codespace://demo-cs/workspaces/repo/
repo @ demo-cs  codespace://demo-cs/workspaces/repo

Locally the same bug is bounded by the existence check: only a real subfolder or worktree of a project could become a second project (graphcode status /repo/docs added "docs").

Naming a path that could not be opened was worse than useless: the refusal was dropped, the CLI waited out its socket timeout, and then reported the command as possibly applied when nothing past the open had been sent.

The fix

• canonicalize normalizes remote spellings the way it has always normalized local ones. Trailing slashes, doubled separators and . segments collapse. Different hosts stay different projects.
• Routing a named path is a policy, not a lookup. For a client that is not the app: a folder inside an existing project is that project, and a remote path the daemon has never seen is refused. Remote projects are added in the app, which validates the connection over ssh first. The app keeps both powers — opening a nested folder and adding a host are deliberate human acts there, and Add Folder still adds a genuinely new folder from a shell.
• Refusals are sent back as errors and both CLIs read them, so a wrong path is one line, immediately, naming the path.
• The remote shim resolves before it opens. It is the one place that knows a bare absolute path is this host's spelling, so /workspaces/repo and worktrees under it address the codespace project they belong to, and it says so on stderr.
• Rows a pre-fix daemon left behind clear themselves out on the next launch — but only the empty ones. A twin that collected loops stays where it is; those loops are somebody's work.

Verified

After the fix, against a live daemon with one codespace project added the way the app adds it:

Command	Before	After
status codespace://cs/workspaces/widget/	second project	the project, instantly
node create codespace://cs/workspaces/widget/worktrees/fix-215 …	third project, loop inside it	loop in the real project
status codespace://other-space/workspaces/widget	fourth project	refused, exit 1, names graphcode projects
status /workspaces/widget (Mac shell)	10s wait, "may have been applied"	refused, exit 1
status /workspaces/widget (shim, on the host)	second project	resolves to the codespace project
status /brand/new/folder	adds it	adds it

Test run: 1518 tests, 157 suites, all passing (10 new, in DuplicateProjectPathTests and RemoteCLIShimTests). swiftlint clean, swift-format clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WYzCYpAW75pcCCDD1eq7wV