Description
Follow-up to #1259 (raised by @will-lamerton in review and by nc-review).
Since #1259, nanocoder daemon start refuses to boot with exit code 1 unless the project root is in preferences.trustedDirectories. nanocoder daemon install was not updated to match: it writes a service definition whose command is nanocoder daemon start, with restart-on-failure set, and reports only Auto-start installed for <root>. (source/daemon/install.ts:268, 297, 332).
If a user installs auto-start before they have ever run nanocoder interactively in that project, the service manager starts a daemon that fails the trust gate immediately, then retries on its restart policy forever. Nothing tells the user why, and install reported success.
Affected on all three platforms:
- systemd user unit:
Restart=on-failure, RestartSec=5
- launchd LaunchAgent:
KeepAlive: true
- Windows Task Scheduler: restart-on-failure
Steps to Reproduce
- Clone any repo you have never opened with nanocoder, so the path is not in
trustedDirectories.
- Run
nanocoder daemon install in it.
- Observe
Auto-start installed for <root>.
- Start the service (or log in again) and check the service manager's state.
Expected Behavior
daemon install tells the user when the project root is not trusted yet, and how to fix it: run nanocoder there once and accept the disclaimer, or pass --trust-directory.
Actual Behavior
install reports plain success. The installed service fails at every start with exit 1 and is restarted indefinitely.
Proposed Fix
- In
install, check trust for opts.projectRoot via isDirectoryTrusted from @/config/preferences.
- When untrusted, keep installing but add a clear warning to the result message naming both remedies.
- Cover it in
source/daemon/install.spec.ts, trusted and untrusted.
nc-review also floated writing Environment=NANOCODER_TRUST_DIRECTORY=1 into the generated unit. I would not do that: it silently grants exactly the trust the gate exists to require, and it would be invisible in the CLI output. Happy to go that way if maintainers prefer.
Additional Context
Description
Follow-up to #1259 (raised by @will-lamerton in review and by nc-review).
Since #1259,
nanocoder daemon startrefuses to boot with exit code 1 unless the project root is inpreferences.trustedDirectories.nanocoder daemon installwas not updated to match: it writes a service definition whose command isnanocoder daemon start, with restart-on-failure set, and reports onlyAuto-start installed for <root>.(source/daemon/install.ts:268, 297, 332).If a user installs auto-start before they have ever run nanocoder interactively in that project, the service manager starts a daemon that fails the trust gate immediately, then retries on its restart policy forever. Nothing tells the user why, and
installreported success.Affected on all three platforms:
Restart=on-failure,RestartSec=5KeepAlive: trueSteps to Reproduce
trustedDirectories.nanocoder daemon installin it.Auto-start installed for <root>.Expected Behavior
daemon installtells the user when the project root is not trusted yet, and how to fix it: runnanocoderthere once and accept the disclaimer, or pass--trust-directory.Actual Behavior
installreports plain success. The installed service fails at every start with exit 1 and is restarted indefinitely.Proposed Fix
install, check trust foropts.projectRootviaisDirectoryTrustedfrom@/config/preferences.source/daemon/install.spec.ts, trusted and untrusted.nc-review also floated writing
Environment=NANOCODER_TRUST_DIRECTORY=1into the generated unit. I would not do that: it silently grants exactly the trust the gate exists to require, and it would be invisible in the CLI output. Happy to go that way if maintainers prefer.Additional Context
nanocoder daemon starthas no directory-trust check; headless mode permits unattended command execution #1245nanocoder daemon starthas no directory-trust check; headless mode permits unattended command execution #1245 touchingsource/daemon/. If it merges, this work needs rebasing onto it.