In the graphcode settings contain Copilot CLI but the new sessions are getting created in claude code

[scgopi]

One of my local loops created two new loops on a codespace, but they both launched as claude code sessions, so they were dead and did nothing. Wonder if there's some gap in loop-initiated new sessions not assuming the right agent default (copilot/claude/codex) ?

[scgopi]

Root cause found — PR #271.

The daemon's create path resolved a new loop's backend in three steps: explicit --backend, then the creating loop's backend if that creator is in the same graph, then a hardcoded .claudeCode. Settings → Sessions (defaultBackend) was never read on that path, though the app's own new-loop form has always read it — so loops you made ran on Copilot and loops your loops made came out Claude Code.

Your case hits the second step's escape hatch: a local loop creating loops in the codespace project passes a createdBy that graph has never heard of (linkToCreator already drops the same id for the same reason), so it fell through to the hardcoded Claude Code. A graphcode node create typed in a plain shell fell through the same way.

Fix: an injected fresh-read onDefaultBackend hook on GraphStore, wired to GraphcodeSettingsStore.load().defaultBackend, applied only after creator inheritance finds nothing. Explicit --backend and a resolvable creator still win.

Separate gap worth its own issue: nothing checks the chosen CLI actually exists on the target host, which is why those two loops were silently dead rather than reporting 'claude: command not found'.