[barelyworkingcode]

Closes #594

Child of #585. An adopted Claude in no project ran headless, and headless forced bypassPermissions in three places, so it ran every tool without asking. An unsandboxed headless session now keeps its own permission mode (default from the adopt); sessions in a project keep bypass, since their sandbox bounds them. Docs: session-adoption.md, session-host.md, THREAT-MODEL.md 3f with promise row TM3f.5, and the G1.54 claim in FEATURES.md.

Fix attempts: 1 (the test needed one setup fix, a mounter credential, that showed only once the fix let the call reach the ask). Tokens: about 460k across planner, test writer, dev and reviewer.

Review notes (minor, not fixed):

• "Only the owner's relay session mode sets bypass" is narrow: eve's set_permission_mode over /ws reaches the same setter. Both are owner actions.
• npWriteHook copies the hook-settings block from g1aSetup; a shared helper would remove the copy.
• One reply check in npAskAndDeny is redundant with the exact match after it.

Red on main: n/a: the bug exists only on the epic branch. Red on the epic head fa33abf: TestAdoptNoProjectAsksForApproval and TestAdoptNoProjectAsksAfterHandBack fail at bug594_unsandboxed_permission_test.go:145 and :158, "the turn answered hook: allow: bypassPermissions mode"
Real-app check: seen before: the relay#587 real-app pass on fa33abf, step 4, no permission prompt and relay-sessions logged decision=allow reason="bypassPermissions mode". Gone after: step 4 of the relay#587 verification rerun on the new epic head
Journey: n/a: no devbox journey reaches a permission prompt on an adopted session; the e2e tests and the real-app step 4 cover it
Break-and-restore: put back if sess.Headless { alone in decidePermission; both no-project tests went red at :145 and :158; restored byte for byte (cmp identical)
Review: no blocking findings (default model, round 1)

🤖 Generated with Claude Code

[barelyworkingcode]

Merged under merge-check: approved, target, contract, evidence, owner, weakening.