feat: enable Remote Control by default with a project-named prefix

[intech]

Stacked on #14 (deps/bump-toolchain-2026-08) because it needs claude-code 2.1.220 to be verified against. Merge #14 first; this PR's base can then be retargeted to main.

What

Remote Control is now on by default for every session, with session names prefixed by the project.

• --remote-control is passed by the entrypoint unconditionally. Opt out with CLAUDE_REMOTE_CONTROL=0 (previously it was opt-in via CLAUDE_REMOTE_CONTROL=1).
• --remote-control-session-name-prefix is passed too. The CLI default for the prefix is the hostname, which inside a container is a throwaway hex id. It now comes from CLAUDE_REMOTE_CONTROL_PREFIX; run_claude.sh and the generated claude-box launcher default it to the host project directory name, and the entrypoint falls back to claude-box.

There is no settings.json key that enables Remote Control (only disableRemoteControl to turn it off), so a CLI flag is the only way to default it on.

Limitation — verified, not assumed

With the inference-only CLAUDE_CODE_OAUTH_TOKEN this image normally runs with, the flag is inert. claude doctor in the built image says so verbatim:

Remote Control
Remote Control requires a full-scope login token. Long-lived tokens (from claude
setup-token or CLAUDE_CODE_OAUTH_TOKEN) are limited to inference-only for
security reasons. Run claude auth login to use Remote Control.
- Sign-in is missing the user:profile scope

To keep this from being a silent dead knob, the entrypoint prints the caveat at startup whenever CLAUDE_CODE_OAUTH_TOKEN is set, and names both remedies (claude auth login inside the container, or CLAUDE_REMOTE_CONTROL=0):

Starting Claude Code in /workspace — permission mode: auto (…); Remote Control
requested (prefix: claude-standalone) but INACTIVE — CLAUDE_CODE_OAUTH_TOKEN is
inference-only. Run 'claude auth login' in this container to use it, or set
CLAUDE_REMOTE_CONTROL=0 to stop asking...

Security posture change

SECURITY.md previously described Remote Control as opt-in and off. It now describes it as a default-on remote-input channel into an agent that has read-write access to the project, and states the opt-out. This is a deliberate loosening of the default; reviewers should read that section.

Prefix sanitisation

The prefix is stripped to [[:alnum:]._-] and truncated to 40 chars. That matters because EXTRA_ARGS is word-split on exec — a prefix containing spaces would otherwise become extra argv entries.

Verification

Built the image, then stubbed claude on PATH to print the argv the entrypoint produces:

case	result
default, token set	--remote-control --remote-control-session-name-prefix <prefix> + INACTIVE notice
CLAUDE_REMOTE_CONTROL=0	no Remote Control flags at all
no token	flags passed, plain "Remote Control on" notice
prefix my proj/../x!;rm -rf	my-proj-..-x--rm--rf, still a single argv token
empty prefix	falls back to claude-box
CLAUDE_BYPASS_PERMISSIONS=1 combined	both flag sets present, messages composed correctly

End to end through the real entrypoint: claude -p returns normally, so the real CLI accepts both flags. bash -n passes on run_claude.sh, install.sh, and the claude-box launcher extracted from its heredoc.

Not verified locally: arm64 (no qemu binfmt on the build host) — covered by the pull_request CI job.

🤖 Generated with Claude Code