fix(safety): confine session work to the project root with explicit consent

[danielgap]

Linked Issue

Part of #1305 (slice 1 of 3; the issue closes with the last slice, not here)

Design thread: the diagnosis and two-layer design are in the issue thread (2026-09-27). This PR is the prompt layer only; the runtime fences (slices 2 and 3) follow the two design questions still open with the reporter (reads-vs-writes scope, bash v1 coverage).

---

PR Type

• Bug fix

---

Summary

• Adds the confinement-and-consent rule to the orchestrator prompt's Safety section: session work stays inside the project root and registered same-clone worktrees; any read or write outside it asks the user first, naming the absolute target; grants are per-target and per-session, and in-project scripts naming outside paths are not standing consent (the sync.bash case from the report).
• Prompt layer of the approved design; no runtime enforcement yet (slices 2-3).

---

Changes

File	Change
assets/orchestrator.md	One Safety rule (+274 bytes; prompt now 7170/8192, 1022 bytes headroom)

---

Test Plan

• node --experimental-strip-types --test tests/orchestrator-budget.test.ts — 34 pass (both 8192-byte budget tests included)
• Prompt-adjacent suites green (gentle-ai, background-subagents, review-ledger-contract, odd-integration, provider-defect-handoff) — 181 pass
• No fixture changes needed: the budget test's Safety indexes map the frozen pre-diet fixture, not the live file

---

Chain Context

Field	Value
Chain	1305-boundary-consent
Position	1 of 3
Base	main
Depends on	#1305 design (posted in-thread); this slice is independent of the two open questions
Follow-up	slice 2 path-tool consent fence (blocked on Q1), slice 3 bash fence (blocked on Q2)
Review budget	1 / 400

Scope

• Includes: prompt rule only
• Excludes: runtime path-tool fence, bash fence, any permission-flow changes

---

Contributor Checklist

• Linked issue is status:approved (bug(harness) Agent left the current project directory (sibling project) without asking for permission #1305)
• Conventional commit format
• Tests green locally
• No Co-Authored-By trailers

Summary by CodeRabbit

• Documentation
  • Clarified that work must stay within the project root or registered worktrees. Accessing paths outside them requires session-specific approval for the named absolute path.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 2ed083ba-8797-45f9-93d7-a3e41dcdfea5

📥 Commits

Reviewing files that changed from the base of the PR and between b27bd32 and 6493a34.

📒 Files selected for processing (1)

• assets/orchestrator.md

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

The orchestrator safety guidance now limits session work to the project root or registered same-clone worktrees. It requires approval before reading or writing outside those locations and defines approval as applying only to the named target for that session.

Changes

Session path boundary

Layer / File(s)	Summary
Session path approval rule assets/orchestrator.md	The Safety section specifies allowed session locations and requires target-specific approval before outside reads or writes. It also states that scripts naming outside paths do not grant standing consent.

Priority: ➖ Normal

Estimated code review effort: 1 (Trivial) | ~3 minutes

Change: Bug fix

Suggested reviewers: alan-thegentleman

Merge Risk: ⚪ Minimal · up to 6493a

The orchestrator now requires target-specific approval before outside-root reads or writes. No actionable merge-blocking issue is evident in this prompt-only change.

Architecture Summary

Architecture risk: 🔵 Low · up to 6493a

The change affects 1 system.

Changed systems: assets

Architecture concerns
No architecture-level concerns identified.

Review details

Systems and components

• observed — assets (service) was modified; 1 changed file maps to changed impact.

Before / after behavior

• observed — Modified behavior in assets/orchestrator.md: Added a Safety rule requiring session work to stay within the project root or registered same-clone worktrees, and requiring target-specific, per-session approval before outside reads or writes.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: restricting session work to the project root and requiring explicit consent for outside paths.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[carlosmoradev]

Clean and focused first slice.

Verified that the prompt addition stays well within the 8,192-byte budget with tests passing cleanly. The explicit clarification that in-project scripts referencing outside paths do not constitute standing consent is a great addition to prevent boundary leakage.

Looking forward to the runtime fences in slices 2 and 3.

[barbatdev]

Could we confirm the reads-vs-writes decision in #1305 before merging this slice? The new prompt rule already requires consent for both reads and writes outside the worktree, while the runtime scope is still an open question in the issue. Confirming that policy now would keep the prompt and the later fence aligned.

[danielgap]

Good question, and the alignment concern is the right one to raise. Two reasons this slice is safe to land before the Q1 decision:

1. The prompt rule encodes the conservative default the approved design already states: consent before any read or write outside the project root. It gates with a question, it does not forbid, so it is a strict superset of every narrower outcome. If the eventual policy lands on writes-only fencing or freely allowed reads, behavior narrows; it never contradicts.
2. If that narrowing happens, the prompt line changes in the same change that lands the matching runtime fence (slice 2), so the prompt and the fence never disagree at rest. That coupling is why the fence slices are blocked on the answers in bug(harness) Agent left the current project directory (sibling project) without asking for permission #1305 rather than shipped alongside this one.

The reads-vs-writes question itself stays open with @x4barin and the maintainers in #1305 (asked 2026-09-27; slices 2 and 3 follow the answer). If a maintainer prefers to hold this slice until Q1 resolves, that works too: it is one prompt line, trivial to rebase. My recommendation is to land it, because the current state (no rule at all) is weaker than every candidate policy, so the superset cannot make the boundary looser than today.