When to invoke

Use when debugging to prevent accidentally "fixing" unrelated code, or when you want to scope changes to one module. Use when asked to "freeze", "restrict edits", "only edit this folder", or "lock down edits".

/freeze — Restrict Edits to a Directory

Lock file edits to a specific directory. Any Edit, Write or NotebookEdit operation targeting a file outside the allowed path will be blocked (not just warned).

Where this is enforced. The block is a Claude Code PreToolUse hook. Cursor, Kiro and Codex install the same skill, but the hook is not guaranteed to run there; outside Claude Code /freeze is instruction-only. On those hosts, tell the user the boundary is advisory: you will keep your own edits inside it, but nothing blocks an edit that lands outside.

Copilot CLI is the exception. When the configuration payload is installed (./install --with-config or --only=config), the user hook file ~/.copilot/hooks/vibestack.json (under $COPILOT_HOME when set) runs the same check on every edit, and it blocks only while a freeze directory is set: after /unfreeze, or before /freeze is ever run, every edit goes through. Without the configuration payload it is instruction-only there as well.

Setup

Ask the user which directory to restrict edits to:

"Which directory should I restrict edits to? Files outside this path will be blocked from editing."

Once the user provides a path, set it with the shared state writer. It resolves the physical absolute path, refuses a path that does not exist or resolves to /, and writes the state file atomically:

bash "${CLAUDE_SKILL_DIR:-$HOME/.claude/skills/freeze}/bin/freeze-state.sh" set "<user-provided-path>"

Report success only if the command exits 0 and prints FREEZE_DIR=. On FREEZE_ERROR (a mistyped or missing path, or /), tell the user no boundary was set and ask for the path again. On FREEZE_BUSY, another writer holds the lock — retry once it finishes, and never write or delete the state file directly.

Tell the user: "Edits are now restricted to <FREEZE_DIR>/. Any Edit, Write or NotebookEdit outside this directory will be blocked. To change the boundary, run /freeze again. To remove it, run /unfreeze."

How it works

The hook parses file_path out of each Edit/Write payload (notebook_path for NotebookEdit), resolves the path fully — including a final component that is itself a symlink — and checks whether it starts with the frozen directory. If not, it returns a hookSpecificOutput envelope carrying permissionDecision: "deny". The nesting matters: Claude Code ignores a top-level permissionDecision, so a deny emitted at the top level lets the edit through.

Freeze is the deny tier, so it fails closed: a payload it cannot parse, a payload with no path, a relative saved boundary, and any unexpected hook error are all blocked, not allowed. Its ask-tier sibling /careful makes the opposite call on the same input. Both share one extractor (careful/bin/hook-extract.sh).

The boundary lives in ~/.vibestack/freeze-dir.txt, not in the session. Ending or killing a conversation stops its hooks but leaves the file in place, so the next session that loads the freeze hook (/freeze, /guard, /investigate) enforces the same boundary again. Only /unfreeze removes it.

Notes

• The trailing / prevents /src from matching /src-old
• Applies to Edit, Write and NotebookEdit only — Read, Bash, Glob, Grep are unaffected
• Bash commands like sed -i can still modify files outside the boundary
• A symlink inside the boundary pointing outside it is resolved and blocked
• A path with spaces in it works — only leading and trailing whitespace is

trimmed from the saved boundary, and a leading ~ is expanded

• To deactivate: run /unfreeze — ending the conversation does not remove the boundary