[baxyz]

What

New remoteControl option for claude-dev (off by default). When on, the devcontainer keeps a Claude Code Remote Control server (claude remote-control) running in a detached tmux session, so sessions can be started and driven in this devcontainer from claude.ai/code or the Claude mobile app — with no VS Code window open on it.

"ghcr.io/helpers4/devcontainer/claude-dev:1": {
  "remoteControl": true,
  // Trusts the server's folder for you: its hooks, MCP servers and permission rules apply to
  // sessions started remotely. Only for code you trust.
  "remoteControlAutoTrust": true
}

First start: log in from the Claude extension, nothing else

The loop waits for the login, then answers the two one-time questions claude remote-control asks, by reading the tmux pane:

• Enable Remote Control? (y/n) → yes (you asked for it with remoteControl);
• Trust <folder>? [y/N] → yes with remoteControlAutoTrust, otherwise no, retried every 30 s until you run claude once in the folder and accept. The Claude extension never sets this trust (it relies on VS Code's Workspace Trust), so it can't be left to the extension.

No claude-rc attach, no claude auth login: the extension login is enough (checked on a fresh devcontainer).

How

• postStartCommand: claude-rc start --lifecycle — runs after postCreateCommand has linked ~/.claude to the volume. Silent no-op when the option is off; never fails the container start (missing CLI/tmux → warning).
• claude-rc (/usr/local/bin): start (idempotent), stop, restart, login, attach (debug), status. Restarts claude remote-control forever, backing off up to 5 min when it keeps exiting right away, 15 s otherwise.
• CLAUDE_CONFIG_DIR=/mnt/h4claude (containerEnv): ~/.claude.json (account, trust, confirmation) lives outside ~/.claude, so the symlink didn't cover it and it was lost on rebuild. It now lives in the volume; an existing home-level file is seeded into it. This applies to every claude-dev user, not only remoteControl.
• Directory: option remoteControlDir → the workspace folder. Not /workspaces with org-workspace: trust is per directory, and /workspaces is neither the folder opened in VS Code nor a git repository.
• Name: remoteControlName → $CLAUDE_RC_NAME → org-workspace's org → origin owner → folder → hostname. It titles the first session and prefixes the others; the environment label in claude.ai/code is the git repository name, which Claude Code doesn't let us set.
• Other options: remoteControlSpawn (same-dir/worktree), remoteControlPermissionMode.
• Warns at startup about env vars that disable Remote Control. remoteControl implies installCli and installs tmux (apt).

Not covered

A headless host (no screen) needs something to run devcontainer up at boot: postStartCommand only runs when devcontainer tooling starts the container, not on a plain docker restart.

Tests

• test.sh (defaults): claude-rc installed, RC_ENABLED=false baked, loop not running.
• with_remote_control scenario: CLI implied, tmux installed, options baked, CLAUDE_CONFIG_DIR set, loop running after postStartCommand, name "h4 test" sanitized to h4-test.
• Checked by hand in a private sandbox devcontainer (local copy of the feature, org-workspace sibling repos): fresh volume, extension login only → server connected and listed in claude.ai/code. Not run: devcontainer features test (no containers under DooD here) — CI is the first run of the test scripts; shellcheck wasn't available either.

Version: 1.3.1 → 1.4.0 (new options). README (feature + root) and AGENTS.md table updated.

🤖 Generated with Claude Code

[github-actions]

✅ PR Validation Passed

All checks passed!

---

📋 Pipeline Status

	Job	Status
✅	🧾 Conventional Commits	passing
✅	🔖 Version Bump	passing
✅	🧪 Feature Tests	passing
✅	🧪 Scenario Tests	passing
✅	🐚 ShellCheck	passing

---

_{🤖 Generated by @helpers4 CI • 2026-10-26}