Documentation
Remote SSH, devcontainers, and WSL
Keep Nightshift’s host, project, state, and watchman on the same side of a remote environment boundary.
Answers: run Nightshift in WSL SSH or a devcontainer · Updated
Co-location is the rule: the coding host process, installed plugin, repository, .nightshift workspace, and watchman must resolve and execute inside the same environment.
Why co-location matters
Process detection, absolute paths, session identity, hooks, and recovery commands must agree about one filesystem and one process namespace. Splitting them produces ambiguous liveness and unsafe recovery.
- Remote SSH: run the host and watchman on the remote machine.
- Devcontainer: keep project, plugin runtime, and watchman inside the container.
- WSL: keep all components inside one distribution.
Linked workspaces
When the host-opened project and the workspace holding .nightshift differ, create the explicit workspace link described by Nightshift. It validates the absolute target and never guesses a nearby folder.
- Use one durable workspace per shift.
- Avoid symlink or mount arrangements that change identity across processes.
- Run Doctor when the resolved paths look wrong.
Conservative failure
If Nightshift cannot prove the environment relationship, it should stand down instead of reviving into a different filesystem or session.
Start with a bounded prompt
This prompt names the outcome and preserves Nightshift’s review boundary. Paste it into the supported coding host from the project you want to change.
Verify that the coding host, plugin, repository, Nightshift state, and watchman all share one process and filesystem boundary.What this workflow does not claim
- A scheduler inside a stopped container cannot restart the container.
- Remote logout, sleep, and process-reaping policy remain controlled by the target environment.
Evidence and sources
These links support the released behavior, public outcomes, or problem language described on this page.