[allens]

Walls the headless clean-room run in, instead of relying on the brief and the transcript audit alone.

Each build now writes session-settings.json beside the clean room, where the session can't reach it to loosen it (sessionSettings). It also prints the run command for its role and platform (runCommand).

What the walls do

• --restricted confines the file tools to the clean room, plus a backup's fixtures through --add-dir. It loads no user settings, so a user-level additionalDirectories can no longer make a folder in home a working directory of the session.
• The shell sandbox, on Linux, WSL and macOS, blocks reads of the home folder outside those directories. It also blocks every host but *.amazonaws.com, for every command and every program the session runs. Windows has no shell sandbox, so there the brief and the audit remain the guard.
• The classifier note. --restricted also drops the user's autoMode.environment, so the settings name the bucket themselves. Without that, a backup's closing empty is refused.
• The tool list. --tools names what past runs used, because --restricted drops every command tool it doesn't name.

Tested

In WSL, with Sonnet 5.5 sessions:

• A real backup build. The fixtures were readable by Read and by the shell, and boto3 reached the bucket. The settings file, ~ and pypi.org were all refused.
• The user's extra working directory. It was readable without --restricted and refused with it.
• Emptying a probe prefix in the backup bucket went through with no classifier denials.

npm test passes, and so do format, lint and typecheck.

Not yet run: macOS, and a Windows build with the new command.

🤖 Generated with Claude Code

[allens-claude-reviewer]

Code review (/code-review high, Opus 5.5): nine findings, most severe first. The first two would stop a run on a platform this PR hasn't tested.