28 Commits

Include renames

Author	SHA1	Message	Date
shadow-testandClaude Opus 5	48d0c3249a	Fix two bugs in last round's fixes, and stop --full hiding the Docker host ... Round 3 found defects in code written an hour earlier. Both reproduced. **The handshake poll accepted empty output as a completed handshake.** `[ "$(… | awk '{print $2}')" != 0 ]` is *true* when `wg show` prints nothing — which it does when the interface has no peer, and when the interface is gone (that message goes to stderr). `until` suspends `set -e` and `pipefail`, so nothing else caught it. The poll added last round to make "success without a tunnel" impossible produced exactly that. Now requires a number greater than zero, and waits 20s rather than 10 so a slow link is not rolled back needlessly. **`down` still sat above the key registration.** Last round moved it below the token and server-list fetches but not below `addKey`, which is the most failure-prone of the three — one gateway, by CN, pinned certificate. So a refused registration still tore down a working tunnel. It now runs after the last fetch; the key is generated before but written after, since `down` deletes it. SKILL.md said "after every network fetch has succeeded", which was false; corrected. **`up --full` made `host.docker.internal` unresolvable — and `status` said DNS was fine.** That name is answered only by the resolver being replaced; it is not in `/etc/hosts`. `gateway.rs` hands it to every container for the LiteLLM gateway, and Ollama and custom endpoints default to it, so an agent running `up --full` silently removed the project's model backend. The route was already excluded; only the name was lost. Now resolved with the old resolver and pinned into `/etc/hosts` before the swap, restored on teardown, and `status` probes it — PIA answers public names happily, which is precisely why probing only `api.anthropic.com` reported "ok". Documented as Trap 4. **The rollback could abort halfway.** The trap's `{ … }` is not exempt from `set -e`, and `down`'s `cat`/`tac`/`rm` had no `|| true` — so one failure left the interface up with all traffic captured, after printing "rolling back". `down` now runs under `set +e`, the trap tolerates its failure, and the interface is deleted *first*, since that removes every route pointing at it. **The account password had a real argv window.** curl does blank `-u`, but only once running: sampling /proc/<pid>/cmdline caught the plaintext in 2 of 400 tries, between exec and the overwrite. Small, but it is the permanent password and the token already had the fix. Moved onto the same stdin config — 0 of 400. Review reported this as a 25-second exposure; that was a wrapper's argv, not curl's. entrypoint: the skill install stages into `$_dest.new` and swaps, so a failed copy leaves the previous copy intact instead of a truncated SKILL.md and no script, root-owned, on a persisted volume. Verified against a size-limited filesystem. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:15:52 -07:00
shadow-testandClaude Opus 5	5b96ad4823	Stop a failed up from tearing down a working tunnel ... The previous commit moved `down` to the top of `up` to fix a resolv.conf idempotency bug, and in doing so put it *before* every network fetch that can fail. Re-review caught it and I reproduced it: with a tunnel up, an `up` that fails on bad credentials left `pia0` gone and traffic silently back on the real address, while the error talked only about credentials. A privacy regression introduced by a correctness fix. `down` now runs after the token, server list and key registration have all succeeded — nothing above that line touches the network stack — and still clears the stale backup it was added for. Everything after it is covered by a rollback. Note this is an EXIT trap with a flag, not `trap ... ERR`: my first attempt used ERR and did not fire at all, because ERR is not inherited by shell functions without `set -E`, so a failure inside add_route missed it, and `die` exits explicitly, which is not an error. Verified by forcing a route collision — the tunnel is torn down and DNS is intact, where before the fix it was left half-configured with DNS dead. Also from the review: - **The private key lived on disk for the whole life of the tunnel.** `commit_container_snapshot` blanks env vars, never files, and nothing tears the tunnel down before a recreate or migrate — so the `down`-time cleanup never covered the path that put a key in a snapshot in the first place. It is now deleted the moment `wg set` has read it; the kernel keeps its own copy, verified by checking the interface still works afterwards. - **`up` claimed success without a handshake.** An unreachable peer still routes — into a black hole — so `up --full` could exit 0 having pointed all traffic and resolv.conf at a peer that never answered, with `status` printing "mode: full tunnel". Now polls for a handshake and rolls back if none arrives. - **`status` needed root and did not check.** `wg show` fails unprivileged and was swallowed, so an unprivileged run printed "no tunnel up" and then "mode: full tunnel" in the same breath. An agent reading the first line would re-run `up` — which, before the fix above, destroyed the tunnel it failed to see. - **The killswitch bullet was false.** It said `iptables` is not in the image; it is, so a killswitch is buildable. It stays unbuilt because it would cut Claude Code's own API traffic — an honest reason, unlike the previous one. - `install_feature_skill` rejects path-traversal names, not just blank ones — verified `../skills` would have deleted the whole skills directory including Mission Control's — and reports `mkdir`/`cp` failures instead of printing a success line regardless. - The usage text ended by printing `set -euo pipefail`, off by one line. - HOW-TO-USE claimed "the container says so on start". entrypoint prints to PID 1's stdout, which no terminal or UI surfaces — `docker logs` appears nowhere in the repo. Now points at the migration pre-flight, which does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:11:50 -07:00
shadow-testandClaude Opus 5	dcb13d23ea	Fix what review found in the skill: five real defects ... Adversarial review of #29 found bugs I confirmed by reproducing each one. **Every hand-written error message was unreachable.** `tok=$(curl ...)` is a plain assignment, so `set -e` acts on the command substitution before the following `|| die` can run. A wrong password produced exit 22 and no output at all — the most likely way this gets used wrongly, and the least explained. All four captures now go through a `run` helper that takes a *description* rather than echoing the command, because one of them carries the account password in `-u`. **`up` was not idempotent, and the second run destroyed DNS.** The resolv.conf backup was copied unconditionally, so `up --full` twice overwrote the good backup with PIA's own resolvers; the later `down` then "restored" those and left the container with no working DNS and no way back. `up` now runs `down` first. Verified: two `up --full` runs, then `down`, and the backup still holds the original 192.168.65.7. **An empty gateway produced total connectivity loss, reported as healthy.** `$gw` was never validated and `add_route` swallowed every failure to /dev/null. The two half-routes need no gateway and would succeed, so the tunnel captured everything while the exclusions keeping DNS and the Docker host reachable silently did not exist — and `status` still printed "full tunnel". Routes are now fatal on failure, and a via-less default (`$3` is the literal "eth0") is rejected. **The PIA session token was in the process arguments** — confirmed in `ps` and /proc/*/cmdline, a ~24h bearer credential for the account readable by anything in the container. It now goes to curl on stdin as a config. Verified: 60 polls across a full `up`, zero sightings. **The preflight diagnosed the wrong kernel module.** It checked /dev/net/tun and blamed the tun module, but kernel WireGuard is a netlink interface and does not use it — verified by creating one with NET_ADMIN and no tun device. The check is dropped (the container could not have started without the device anyway) and `ip link add` now reports the real dependency. Also: a full tunnel with no DNS servers from PIA used to warn and carry on, which is a tunnel leaking every lookup while reporting itself healthy — now fatal. `down` validates the backup before restoring it, so a truncated one cannot leave the container with no resolver at all. `wg.priv` is shredded on teardown and created under umask 077, because /run rides `docker commit` into the snapshot image. A mistyped `up --ful` is rejected instead of silently giving a test route. entrypoint: `install_feature_skill` gets `local`, a blank-name guard (the disabled branch would otherwise `rm -rf` the whole skills directory under a persisted volume), `-e`/`-L` so a leftover *file* at the destination is cleaned up, and a chown of the parent so `claude` can still add skills of their own when Mission Control is off. When the base image predates the skill it now says so instead of returning silently — and `/opt/triple-c-skills` joins FEATURE_PROBES so the migration pre-flight reports it. Docs corrected to match: neither half reaches an existing project without a migration. `vpn_env_var` extracted and tested, pinning the property the whole removal path rests on — that the variable is emitted as 0 rather than omitted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:11:50 -07:00
shadow-testandClaude Opus 5	3bd3caa101	Ship a pia-vpn skill with the VPN support toggle ... The toggle grants CAP_NET_ADMIN and /dev/net/tun and stops there, which users reasonably read as "turn the VPN on" — the gap between the two is the reported bug that the default network does not route through a VPN. Close it by giving the container an agent-usable way to build the tunnel, rather than leaving each project to rediscover it. container/skills/ is baked to /opt/triple-c-skills and installed into ~/.claude/skills/ by entrypoint.sh from VPN_SUPPORT_ENABLED, mirroring how Mission Control installs its own. Staged under /opt because ~/.claude is a volume mount that would mask an image copy from first start. Three details that are not incidental: - The variable is sent as 0 rather than omitted when off, because ~/.claude persists: entrypoint has to be *told* to remove a skill left by an earlier run with the toggle on, and an absent variable cannot say that. A stale skill is worse than none, since it instructs an agent to use a capability the container no longer has. - It is reserved in RESERVED_ENV_EXACT alongside MISSION_CONTROL_ENABLED, or a custom env var of the same name could claim the skill without the capability behind it. Covered by a test. - The skill is re-copied on every start, rm -rf'd first, so fixes reach existing projects and files dropped from a later version do not linger. The skill itself carries the three things that are easy to get wrong: that a full tunnel captures the Docker resolver and takes DNS down with it, that an IP-literal health check cannot see a dead resolver, and that no tunnel survives a restart while /run state riding the snapshot makes it look as though one did. It also states what it deliberately does not do — no killswitch, no autostart — so an agent proposes those as decisions rather than improvising them. pia-wg.sh preflights CAP_NET_ADMIN by capability bit rather than letting the first `ip` call fail with a bare EPERM that points nowhere near the setting that needs changing. Credentials stay in a file (~/pia-creds, PIA_CREDS to override) rather than the environment, where docker inspect and every process in the container would see them. Tested: install/refresh/remove/no-op paths of install_feature_skill against the real function; preflight with and without the capability; and a full up --full / down round trip, confirming DNS via PIA's resolvers, api.anthropic.com reachable through the exit, and routes and resolv.conf restored on teardown. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:11:23 -07:00
shadow-testandClaude Opus 5	f3cc1c4c17	Stop Playwright setup from deleting the package it just installed ... Setting up the browser view failed on every container, and re-running it reproduced the same broken state, because the setup destroyed its own work. `install_packages` ran two `npm install --no-save` commands into /workspace, which has no package.json. With no manifest, npm treats the command line as the whole statement of what the tree should contain and prunes the rest, so installing `playwright` second removed the `@playwright/cli` installed first: "removed 3 packages", leaving an empty node_modules/@playwright/ behind playwright and playwright-core. That empty directory is exactly what the pane then reported as missing. The second install now names both specs; the first one is already present, so it costs nothing and is only there to stop npm pruning it. Two failures were waiting behind that one: Nothing in the tree ever configured the browser, so playwright-cli fell back to channel `chrome` — system Google Chrome — with the Chromium sandbox on. These containers forbid unprivileged user namespaces, so it aborted with "Failed to move to new namespace ... Operation not permitted"; on a base image without Google Chrome the same default failed as "Chromium distribution 'chrome' is not found". entrypoint.sh now seeds ~/.playwright/cli.config.json on every start, which is the only way to reach existing projects: ~/.playwright is inside the home volume, so an image copy would reach new projects only. The launch check passed for a configuration the viewer never uses. It launched bundled chromium with no channel, which resolves to chromium-headless-shell, while the viewer's config pins chrome-for-testing — the full chromium build, a separate download. A container could pass every check and still fail in the pane with 'Browser "chrome-for-testing" is not installed', which is what a stale chromium-1217 against a wanted chromium-1237 did. Chromium is now verified on both channels, the sandbox setting is stated rather than inherited from a default, and a failure names the channel. triple-c-playwright-heal repairs all of it on a container that is already broken, including the missing socat that makes the pane report "127.0.0.1 sent an invalid response" while the container side is perfectly healthy. It verifies by launching a browser rather than trusting the preceding steps — which is how the stale-revision case was found — and lives in /usr/local/bin so a fix to it can still reach an existing project. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 21:24:37 -07:00
shadow-testandClaude Opus 5	9027fa9ad4	Stop the scheduler handing Claude root's HOME ... Every scheduled task failed with "Not logged in · Please run /login" while the container's OAuth credential sat there, valid, the whole time. The entrypoint snapshots the environment into ~/.claude/scheduler/.env so cron jobs get more than cron's minimal env. It runs as root, and HOME was in the capture list, so the file recorded HOME=/root. The task runner then sources that file with `set -a`, overwriting the HOME cron gave the job. `claude -p` looks for its credential under $HOME, finds no /root/.claude, and exits 1. Logging still worked — SCHEDULER_DIR is expanded before the sourcing — which is why this presents as a well-formed log of a task that never authenticated. Drop HOME from the captured set and write it explicitly instead; cron does still need one. Then restore HOME across the source in the task runner too: .env lives on the home volume, so every project created before this ships keeps a stale copy of it until its container restarts, and the runner is what has to survive that. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 06:13:59 -07:00
Claude	7a5823cb2b	Inject the corporate CA certificate into containers ... Behind a TLS-terminating corporate proxy every HTTPS call inside a container fails — npm, pip, git, curl, the browser-view pane, and Claude Code's own API requests. There was no mechanism at all: installing the certificate by hand inside a container is lost on Reset and had to be repeated per project. A global CA path in AppSettings with a per-project override on Project, taking either a single certificate file or a directory. It is bind-mounted read-only at /tmp/.host-ca (mirroring /tmp/.host-ssh and /tmp/.host-aws) and applied by entrypoint.sh on every start, so it survives recreation, migration and Reset. Four things this gets right that are easy to get wrong: * update-ca-certificates globs *.crt case-sensitively, so a .pem that is merely copied in is ignored in silence. Certificates are renamed, by container_cert_name() in Rust and a mirrored few lines of shell. * The system store only serves curl/git/apt. Node — and so Claude Code itself — needs NODE_EXTRA_CA_CERTS, Python needs REQUESTS_CA_BUNDLE/SSL_CERT_FILE, and Chromium reads neither: it wants ~/.pki/nssdb, seeded with certutil (libnss3-tools, added to the image). * Those vars are set from Rust at creation, never exported by the entrypoint — a terminal is a docker exec and sees nothing the entrypoint exported. They are emitted empty when no CA is configured, since docker commit bakes env into the snapshot image. * triple-c.ca-fingerprint hashes the certificate bytes as well as the path, so a CA rotated in at the same location still forces a recreation. Verified end to end against a real container and a self-signed CA: curl, node, python and git all complete a TLS handshake against a server signed by it and all three fail in the same container without it; the env vars are visible from a docker exec session; the store is cleaned when the setting is cleared. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k	2026-08-10 10:40:21 -07:00
shadow-testandClaude Opus 5	d42b741337	Migrate a project onto a new base image without losing its volumes ... Projects were pinned to the image they were first created from. Both create paths preferred triple-c-snapshot-<id>:latest whenever it existed, and container_needs_recreation compared the container's live image against the triple-c.image label — which create_container wrote from the same image it created from. A tautology that could never fire. The only escape was Reset, which calls remove_project_volumes and destroys the login, skills and transcripts. Measured consequences on this host: real projects are missing socat (so the auth bridge cannot tunnel) and bubblewrap (so sandbox mode does not work), plus Mission Control and triple-c-sso-refresh, and sit 61 packages behind the base including ca-certificates, openssl and curl. Detection. create_container now writes triple-c.base-image-id (the image ID, not RepoDigests, which local-built and custom images do not have) and triple-c.create-image. container_needs_recreation takes the expected create-image and compares against the latter, so the check means something. base-image-id is deliberately NOT compared: a base bump would otherwise silently recreate from the snapshot, consuming the "you should migrate" signal without migrating. Staleness is surfaced, never acted on automatically. Migration keeps the volumes. /home/claude and ~/.claude are volumes and the image's copy is seed-only — permanently masked after first mount — so the login, ~/.claude.json, skills, transcripts, scheduler tasks, SSH keys, cargo, uv, ruff and Claude Code itself re-attach untouched. Only root-level state is rebuilt: apt packages are replayed against the new base rather than copied, so no stale libc is dragged forward, and /usr/local, /opt and the non-bind-mounted parts of /workspace are copied verbatim with tar --skip-old-files so they can never clobber a newer base binary. docker diff is not used: on a snapshot-derived container it reports only changes since the last commit. Raw image-vs-image diffing is filtered through dpkg ownership because it otherwise lies — 8,677 raw path differences on a real project reduced to 2 genuinely user-authored files, both loose /workspace-root files. Crash safety. snapshot:latest keeps pointing at the old image until the final commit, so any crash before it self-heals on next start. Later crashes are caught by reconcile_project_statuses. The rollback pin is a docker tag: 0.057s and 0 bytes. Rollback restores the system layer only — volumes are never touched — and the UI says so rather than implying a time machine. Fixes an infinite recreation loop shipped with the MCP removal. docker commit propagates labels to the image, so a container created from a snapshot inherited its non-empty triple-c.mcp-fingerprint and the one-shot shim recreated it again on every start, forever. Lineage labels are now always written explicitly. Documents the second, separate bug this uncovered: Dockerfile changes under /home/claude never reach an existing project, migration or not, because the volume masks them. Anything that must stay upgradable belongs in /usr/local/bin or /opt, or must be seeded by entrypoint.sh. 145 Rust tests, 227 frontend tests, both builds clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 18:19:12 -07:00
shadow-testandClaude Opus 5	cc5f691677	Add llama.cpp backend, model gateway, URL relay and browser view ... Four features, plus a latent bug fix. llama.cpp backend. Claude Code only ever speaks the Anthropic Messages API — confirmed empirically by pointing it at a logging server, which received POST /v1/messages?beta=true. llama-server implements that natively (verified in its README, alongside --port default 8080), so this is a plain base-URL backend with no translation shim, the same shape as Ollama. Its --api-key defaults to none, so the auth token is a placeholder Claude Code requires and llama-server ignores. Model alias fix. ANTHROPIC_DEFAULT_HAIKU_MODEL is documented as "also used for background functionality", and Triple-C set none of the alias vars. So on every custom-endpoint backend, Claude Code resolved `haiku` to an Anthropic model id and sent it to a local server that does not have it — background features failed silently. All four ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU,FABLE}_MODEL vars are now pinned to the backend's configured model, with an optional Haiku override, and blanked for Anthropic and Bedrock so those keep Claude Code's defaults. The deprecated ANTHROPIC_SMALL_FAST_MODEL is never emitted. Existing Ollama and OpenAI-Compatible containers are recreated once so the new env reaches them; the snapshot is preserved. Model gateway. Optional LiteLLM sibling container, off by default, mirroring stt.rs — this is what makes real OpenAI usable, since api.openai.com has no /v1/messages. Pinned to v1.96.0 by tag and digest: the 1.82.7/1.82.8 malware was PyPI-only and never affected the official images, which is precisely why this builds FROM the image rather than pip-installing, but 1.84.0 is still the floor for proxy CVEs (API-key SQLi, Host-header auth bypass, MCP auth bypass). Binds 0.0.0.0 because project containers consume it, and therefore always sets a master_key — LiteLLM without one accepts any key. The provider key lives in the OS keychain and is uploaded into a volume, never an image layer or label. URL relay. A container-side xdg-open/BROWSER shim opens URLs in the host's browser. Uses an OSC sequence to /dev/tty rather than a printed sentinel, because the shim usually runs as a grandchild of a process capturing its children's output. Degrades to printing the URL when no terminal is attached, so scheduled tasks do not hang. Only http/https, with control characters rejected before new URL() — which strips newlines, so java\nscript: would otherwise parse as javascript:. Nothing auto-opens; the user confirms. The web terminal shows a tap-to-open banner instead, since that browser may be a phone across a tunnel. Browser view. A Project Home tab that watches and takes over the browser Claude drives with Playwright, using Playwright's own dashboard. Zero image cost — Playwright stays user-installed. It does not reuse the auth bridge's PortForward, which binds an unauthenticated port: correct for a throwaway OAuth listener, wrong for mouse and keyboard control of a browser in a passwordless-sudo container. Instead a token-gated loopback proxy checks Host, then token or a forbidden-header origin signal, before a byte reaches the container. Host ports are confined to 47820..=47827 so CSP frame-src can enumerate them rather than widening to a wildcard, with a test asserting the two agree. 188 frontend tests, 107 Rust tests, both builds clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 16:55:28 -07:00
shadow-testandClaude Opus 5	0ac4e5030c	Add permission modes and container introspection backend ... Permission modes: replaces the binary full_permissions flag with a PermissionMode enum (Plan/Default/AcceptEdits/Bypass). Flag mapping is defined once in PermissionMode::cli_args() and used by the terminal, the web terminal, and the scheduler: Plan -> --permission-mode plan Default -> (no flag) AcceptEdits -> --permission-mode acceptEdits Bypass -> --dangerously-skip-permissions Choices verified against `claude --permission-mode` on 2.1.226. full_permissions is retained and effective_permission_mode() falls back to it, so existing projects.json needs no migration. Bug fix: triple-c-task-runner ran `claude -p ... --dangerously-skip- permissions` unconditionally, ignoring the project's setting entirely. It now reads TRIPLE_C_PERMISSION_MODE, which is injected into the container, added to the reserved env blocklist, propagated through the entrypoint's cron env filter, and tracked by a new triple-c.permission-mode label so a change forces recreation. Introspection: new commands/inspect_commands.rs exposes read-only views into the container over docker exec — Claude sessions (parsed from ~/.claude/projects/<cwd>/<uuid>.jsonl), installed capabilities (skills, agents, commands, hooks, plugins, natively-configured MCP servers), and the triple-c-scheduler task list, logs and notifications. Task/session ids are validated against a strict allowlist and every parameterized call runs as a bare argv vector via bollard, so no shell is involved. Stopped containers return empty results rather than errors. No UI yet; that lands with the Project Home view. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 10:51:34 -07:00
shadow-testandClaude Opus 5	d0bb631d4d	Remove MCP backend, entrypoint injection, and docs; add migration shim ... Completes the removal begun in the previous commit. Backend: deletes models/mcp_server.rs, storage/mcp_store.rs and commands/mcp_commands.rs, the McpStore on AppState, the four IPC handlers, Project::enabled_mcp_servers, build_mcp_servers_json(), compute_mcp_fingerprint(), the MCP_SERVERS_JSON env injection, the mcp-fingerprint label, and the whole MCP container lifecycle. create_container() and container_needs_recreation() lose their mcp_servers/network_name parameters. Container: entrypoint.sh no longer merges MCP_SERVERS_JSON into ~/.claude.json. MCP_SERVERS_JSON stays in the reserved env blocklist. Security: the Docker socket is no longer auto-mounted for stdio+Docker MCP servers — it now mounts only when allow_docker_access is set. Migration: old containers were created with network_mode=triple-c-net-<projectId> and refuse to start once that network is gone. docker/network.rs becomes docker/legacy_cleanup.rs with label-driven, best-effort removal of leftover MCP containers and the per-project network, called on both delete and recreate. container_needs_recreation() now forces a rebuild for any container carrying a non-empty triple-c.mcp-fingerprint label or attached to a triple-c-net-* network, moving it onto the default bridge. Both can be dropped a release later. Docs: drops the MCP sections from README/HOW-TO-USE/TECHNICAL and adds a short note pointing at Claude Code's native `claude mcp` / `/mcp` / .mcp.json instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 10:31:18 -07:00
shadow-testandClaude Opus 5	7c39e3cf11	Fix conflicting --global/--file flags in entrypoint git config ... git rejects `--global` and `--file` together ("error: only one config file at a time"), so the credential helper and user.name/user.email were never written — /home/claude/.gitconfig was left nonexistent and containers had no git identity or HTTPS token helper. Drop `--global` and keep `--file /home/claude/.gitconfig`, which is the intended target: the entrypoint runs as root at that point, so `--global` would have resolved to /root/.gitconfig, and the existing `chown claude:claude /home/claude/.gitconfig` already assumes the --file path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 06:05:06 -07:00
shadow-testandClaude Opus 4.8	0945e21eb1	Address second review pass: fix start-time race + minor cleanups ... - M1 (race): don't mount the host AWS dir for static-credential Bedrock. sync_bedrock_credentials() is the sole writer of ~/.aws/credentials in that mode, and mounting /tmp/.host-aws let the entrypoint's `rm -rf ~/.aws; cp -a` race that write at startup (only when a global aws_config_path was also set). Static keys + AWS_REGION env are self-sufficient and don't need the host config, so skipping the mount removes the dual-writer entirely. - L-a: exit codes are now read via wait_for_exec_exit(), which polls inspect_exec until the exec reports finished, so a non-zero tar/cred exit isn't missed by reading exit_code too early. The backup only fails on a definitively non-zero code (falls back to the empty-output check if undeterminable). - L-b: fixed two comments that referenced the old write_bedrock_static_credentials name (now sync_bedrock_credentials). - L-c: entrypoint only rewrites ~/.claude.json when awsAuthRefresh is actually present, avoiding a needless jq reformat on every non-SSO start. - L-d: backup script traps EXIT to remove its mktemp staging dir even when tar fails, so failed backups don't accumulate temp dirs (with the sanitized config copy) in the container. L-e (drop routing) is a non-issue: the layout is tabbed, so only one terminal pane is ever visible; the active-guard routing is correct. Verified the race fix, trap cleanup, grep guard, and exit-code polling. cargo check / tsc / vitest all pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-30 14:59:48 -07:00
shadow-testandClaude Opus 4.8	424ab04ca8	Fix stale AWS/Bedrock auth carrying over on backend switch ... When a project switched backends (e.g. Bedrock -> Anthropic), the recreated container kept authenticating against Bedrock, and SSO kept firing after switching away. Three root causes, all fixed: 1. Recreation builds the new container from a `docker commit` snapshot. commit always bakes the previous container's full ENV into the image (an empty commit Config does NOT strip it, and the commit API cannot remove env). So CLAUDE_CODE_USE_BEDROCK=1 / AWS_* survived into the new container. Fix: create_container now explicitly clears every managed auth key the active backend does not set (MANAGED_AUTH_KEYS), so create-time env overrides the stale baked-in values. 2. awsAuthRefresh was written into ~/.claude.json (persisted home volume) and never removed, so Claude Code kept invoking triple-c-sso-refresh after switching to a non-SSO backend. Fix: entrypoint now deletes awsAuthRefresh when AWS_SSO_AUTH_REFRESH_CMD is unset, idempotent both ways. 3. Static/session AWS creds were baked into Config.Env at create time, so a stop/start kept stale creds and rotated keys never refreshed without a full recreation. Fix: static creds are no longer injected as env vars; write_bedrock_static_credentials() writes ~/.aws/credentials (0600, secrets via exec env not argv) on every start, and removes a stale ~/.aws/config left from a prior profile/SSO session. Static creds also dropped from the bedrock fingerprint so a key rotation refreshes in place instead of forcing recreation. Adds exec_oneshot_env() for env-carrying one-shot execs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-30 13:34:43 -07:00
shadow-testandClaude Opus 4.8	7f8102985e	Update Claude on container start; harden file-list scroll ... Add a time-bounded `claude update` to entrypoint.sh that runs as the claude user before the container is marked ready, so every terminal session launches the latest CLI. Non-fatal and capped at 120s so an offline/slow network never blocks container readiness; PATH covers both ~/.claude/bin and ~/.local/bin install locations. Add flex-shrink-0 to the FileManagerModal header/footer so a long file list can't squeeze them and the scroll region stays robust. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 15:24:37 -07:00
shadow-testandClaude Opus 4.6	d6ac3ae6c6	Add Claude Code settings infrastructure, TUI mode, session naming, and global defaults ... Adds first-class support for Claude Code CLI features (2.1.71-2.1.110): - New ClaudeCodeSettings struct with per-project and global defaults for TUI mode, effort level, focus mode, thinking summaries, session recap, auto-scroll, env scrub, and 1-hour prompt caching - Settings injected as env vars (CLAUDE_CODE_NO_FLICKER, etc.) and ~/.claude/settings.json entries via entrypoint.sh merge block - New ClaudeCodeSettingsModal component for configuring settings - Session naming support (-n flag passed to claude CLI, shown in tabs) - Relaxed reserved prefix filter: CLAUDE_CODE_* env vars now allowed in custom env vars UI for power users - Global SSH key path, git name, and git email now used as fallbacks when per-project values are not set, with UI in SettingsPanel - Fingerprint-based change detection triggers container recreation when Claude Code settings change - Updated README, HOW-TO-USE, and CLAUDE.md documentation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-16 08:46:03 -07:00
shadow-testandClaude Opus 4.6	2dffef0767	Bundle mission-control into Triple-C instead of cloning from GitHub ... The mission-control (Flight Control) project is being closed upstream. This embeds the project files directly in the repo under container/mission-control/, bakes them into the Docker image at /opt/mission-control, and copies them into place at container startup instead of git cloning from GitHub. Also adds missing osc52-clipboard, audio-shim, and triple-c-sso-refresh to the programmatic Docker build context in image.rs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-03 09:09:15 -07:00
shadow-testandClaude Opus 4.6	2dce2993cc	Fix AWS SSO for Bedrock profile auth in containers ... SSO login was broken in containers due to three issues: the sso_session indirection format not being resolved by Claude Code's AWS SDK, SSO detection only checking sso_start_url (missing sso_session), and the OAuth callback port not being accessible from inside the container. This fix runs SSO login on the host OS (where the browser and ports work natively) by having the container emit a marker that the Tauri app detects in terminal output, triggering host-side `aws sso login`. The entrypoint also inlines sso_session properties into profile sections and injects awsAuthRefresh into Claude Code config for mid-session refresh. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-11 12:24:16 -07:00
shadow-testandClaude Opus 4.6	b7585420ef	Reconcile project statuses against Docker on startup, update docs and CI ... - Add reconcile_project_statuses command that checks actual Docker container state on startup, preserving Running status for containers that are genuinely still running and resetting stale statuses to Stopped - Add is_container_running helper using Docker inspect API - Frontend calls reconciliation after Docker is confirmed available - Update TECHNICAL.md project structure, auth modes, and file listings to match current codebase - Update README.md and HOW-TO-USE.md with MCP servers, Mission Control, file manager, bash shells, clipboard/audio shims, and progress modal docs - Add workflow file self-triggers to CI path filters for build-app.yml and build.yml - Install Mission Control skills to ~/.claude/skills/ in entrypoint Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-10 08:29:06 -07:00
shadow-testandClaude Opus 4.6	429acd2fb5	Add Mission Control integration with per-project toggle ... When enabled, the entrypoint clones mission-control into ~/mission-control (persisted on the home volume) and symlinks it to /workspace/mission-control. Flight Control global and project instructions are programmatically appended to CLAUDE.md. Container recreation is triggered on toggle change. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-05 19:32:04 -08:00
shadow-testandClaude Opus 4.6	d56c6e3845	fix: validate AWS SSO session before launching Claude for Bedrock Profile auth ... When using AWS Profile auth (SSO) with Bedrock, expired SSO sessions caused Claude Code to spin indefinitely. Three root causes fixed: 1. Mount host .aws at /tmp/.host-aws (read-only) and copy to /home/claude/.aws in entrypoint, mirroring the SSH key pattern. This gives AWS CLI writable sso/cache and cli/cache directories. 2. For Bedrock Profile projects, wrap the claude command in a bash script that validates credentials via `aws sts get-caller-identity` before launch. If SSO session is expired, runs `aws sso login` with the auth URL visible and clickable in the terminal. 3. Non-SSO profiles with bad creds get a warning but Claude still starts. Non-Bedrock projects are unaffected. Note: existing containers need a rebuild to pick up the new mount path. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-04 11:41:42 -08:00
shadow-testandClaude Opus 4.6	625d48a6ed	feat: add MCP server support with global library and per-project toggles ... Add Model Context Protocol (MCP) server configuration support. Users can define MCP servers globally (new sidebar tab) and enable them per-project. Enabled servers are injected into containers as MCP_SERVERS_JSON env var and merged into ~/.claude.json by the entrypoint. Backend: McpServer model, McpStore (JSON + atomic writes), 4 CRUD commands, container injection with fingerprint-based recreation detection. Frontend: MCP sidebar tab, McpPanel/McpServerCard components, useMcpServers hook, per-project MCP checkboxes in ProjectCard config. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-04 08:57:12 -08:00
shadow-testandClaude Opus 4.6	2e81b52205	Add container-native scheduled task system with timezone support ... Introduces a cron-based scheduler that lets Claude set up recurring and one-time tasks inside containers. Tasks run as separate Claude Code agents and persist across container recreation via the named volume. New files: - container/triple-c-scheduler: CLI for add/remove/enable/disable/list/logs/run/notifications - container/triple-c-task-runner: cron wrapper with flock, logging, notifications, auto-cleanup Key changes: - Dockerfile: add cron package and COPY both scripts - entrypoint.sh: timezone setup, cron daemon, crontab restore, env saving - container.rs: init=true for zombie reaping, TZ env, scheduler instructions, timezone recreation check - image.rs: embed scheduler scripts in build context - app_settings.rs + types.ts: timezone field - settings_commands.rs: detect_host_timezone via iana-time-zone crate - SettingsPanel.tsx: timezone input with auto-detection Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-01 15:57:22 +00:00
shadow-testandClaude Opus 4.6	265b365f0b	Fix security: enable CSP and eliminate shell injection in entrypoint ... - Enable restrictive Content Security Policy in tauri.conf.json instead of null (disabled), restricting scripts/connects to self + Tauri IPC - Fix shell injection in entrypoint.sh by replacing su -c with direct git config --file writes, preventing names with quotes (e.g. O'Brien) from breaking startup or enabling code execution Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-28 20:43:04 +00:00
shadow-testandClaude Opus 4.6	82c487184a	Add custom env vars and Claude instructions for projects ... Support per-project environment variables injected into containers, plus global and per-project Claude Code instructions written to ~/.claude/CLAUDE.md inside the container on start. Reserved env var prefixes are blocked, and changes trigger automatic container recreation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-27 18:39:20 -08:00
shadow-testandClaude Opus 4.6	0f188783e1	Add container registry pull, image source settings, and global AWS config ... Support pulling images from registry (default: repo.anhonesthost.net/cybercovellc/triple-c/triple-c-sandbox:latest), local builds, or custom images via a new settings UI. Add global AWS configuration (config path auto-detect, profile picker, region) that serves as defaults overridable per-project for Bedrock auth. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-27 15:22:49 +00:00
shadow-testandClaude Opus 4.6	625260b060	Fix UID/GID mismatch and SSH key permissions in container ... - Entrypoint now runs as root to remap the container's claude user UID/GID to match the host user, fixing bind mount permission errors on WSL - SSH keys are mounted read-only to a staging path (/tmp/.host-ssh) and copied to ~/.ssh with correct permissions by the entrypoint - Exec sessions explicitly run as the claude user - Host UID/GID detected automatically and passed as env vars Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-27 04:36:01 +00:00
shadow-testandClaude Opus 4.6	97a0745ead	Initial commit: Triple-C app, container, and CI ... Tauri v2 desktop app (React/TypeScript + Rust) for managing containerized Claude Code environments. Includes Gitea Actions workflow for building and pushing the sandbox container image, and a BUILDING.md guide for manual app builds on Linux and Windows. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-27 04:29:51 +00:00