Use shared ~/.harper-dev/<project>/ parent + document sandbox permission - #28
Use shared ~/.harper-dev/<project>/ parent + document sandbox permission#28hdbjeff wants to merge 2 commits into
Conversation
Replace per-project ~/.<project>-dev/ with shared ~/.harper-dev/<project>/ parent so a single sandbox-write allowlist entry covers all Harper projects on a host. Adds an AI-agent sandbox subsection under §3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
heskew
left a comment
heskew
left a comment
There was a problem hiding this comment.
One actionable configuration defect in the new sandbox subsection needs fixing; details are inline. The path migration itself is internally consistent.
This PR is stacked on skills#26 (feat/add-worktree-dev-rule), which still has an unresolved changes-requested review about moving the rule into a dedicated local-development skill and linking it from the skill indexes. #28 should follow/rebase onto that eventual structure rather than merge independently.
Review coverage: Codex exact-head documentation/configuration pass. Gemini/agy was unavailable for this queue pass.
🤖 Posted by Codex on behalf of @heskew
|
|
||
| ```json | ||
| { | ||
| "filesystem": { |
There was a problem hiding this comment.
This settings shape is not recognized by current Claude Code: filesystem sandbox paths live under sandbox.filesystem, not a top-level filesystem key, so following this example does not grant the promised write access. Please use the current portable form:
{
"sandbox": {
"filesystem": {
"allowWrite": ["~/.harper-dev"]
}
}
}Using ~ also avoids hard-coding macOS's /Users/<user> layout. Current schema: https://code.claude.com/docs/en/sandboxing#granting-subprocess-write-access-to-specific-paths
|
|
||
| ### AI-agent sandboxes: allow writes to `~/.harper-dev/` | ||
|
|
||
| If you run Harper dev under a sandboxed AI agent (Claude Code, Cursor, etc.) that enforces a write-path allowlist, add the shared data-root path so the agent can scaffold and use per-worktree data roots without per-project tweaks. With the data root nested under `~/.harper-dev/<project>/`, one literal allowlist entry covers every Harper project on the host. |
There was a problem hiding this comment.
Non-blocking: the convenience comes with a trust-boundary change worth stating. Allowing the shared parent lets an agent launched from one Harper project mutate every project's dev root under ~/.harper-dev, including another running instance. These roots are disposable and source trees remain outside, so the tradeoff can be reasonable; please mention it and offer ~/.harper-dev/<project> as the least-privilege option for stricter setups.
2 participants
Amends the running-dev-instances-in-worktrees rule (#26) with two changes that came out of adopting it on a real project under a sandboxed AI agent:
Nest per-worktree data roots under a single shared parent. Today the rule prescribes `
/.-dev/hdb-/` — one parent per project. For machines that sandbox AI-agent file writes, this means one allowlist entry per Harper project on the host. Move to `/.harper-dev//hdb-/` so a single literal allowlist entry covers them all.Document the sandbox-permission step. The rule mentions sandboxes adjacently but doesn't say "and your AI-agent sandbox needs to be told to allow writes here." Adds an explicit subsection under §3.
Path change
Before:
```
~/.project1-dev/hdb-/
~/.project2-dev/hdb-/
~/.project3-dev/hdb-/
```
After:
```
~/.harper-dev/project1/hdb-/
~/.harper-dev/project2/hdb-/
~/.harper-dev/project3/hdb-/
```
Most sandbox path matchers don't expand globs (`/Users//-dev` is a literal string), and even if they did, leading-dot dirs are usually excluded from `` by default.
Migration
Backwards-incompatible. Old data at `~/.-dev/` is safe to `rm -rf`; first run after this lands re-scaffolds at the new path.
Other benefits
🤖 Generated with Claude Code