Documentation
Configure Nightshift safely
Set deadlines, stalls, command rules, path protections, identity expectations, and question-tool behavior.
Answers: configure Nightshift safely · Updated
Start with the smallest configuration that expresses the boundary you need. Keep the rules understandable, run the first shift attended, and add cost or stall limits when a finite task must not run indefinitely.
Cost and time boundaries
Finite work normally ends when the list is complete. Open-ended walkthroughs require a deadline. Past quitting time, Nightshift starts nothing new but finishes the current unit before clocking out.
- Deadline: the boundary for open-ended work.
- Stall maximum: how many no-progress cycles are tolerated.
- Watch interval: how frequently recovery checks run.
Owner-defined rules
Rules can deny tool or command patterns, protect directories, and check Git identity or configured secret patterns. The owner chooses them; Nightshift does not silently impose a policy.
- Prefer explicit paths over broad wildcards.
- Never weaken a known house rule during a shift.
- Keep secret values out of committed configuration.
Permissions are separate
An unattended process cannot approve prompts. Configure host permissions before leaving, while remembering that Nightshift’s own guards remain active inside the permissions mode you choose.
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.
Review Nightshift's available rules for this project and propose a minimal configuration with a deadline, STOP path, and only the guards I need.What this workflow does not claim
- Broad regular expressions can block legitimate work and should be tested attended.
- Secret-pattern checks reduce accidental commits but do not replace secret management.
Evidence and sources
These links support the released behavior, public outcomes, or problem language described on this page.