42 Commits

Include renames

Author	SHA1	Message	Date
shadow-testandClaude Opus 5	5dd1ab5217	Stop resting the iptables case on a kernel config I cannot verify ... Round 3 argued the macOS rationale is stale: that Docker Desktop no longer builds from linuxkit/linuxkit and has enabled nft_fib_ipv4 since 4.35. I could not confirm or refute that from a Linux host — searching turned up no version matrix either way. But the decision does not depend on it, and the comment should not have implied it did. `xt_CONNMARK`, which the iptables path needs, was present in every kernel config examined. `nft_fib_ipv4`, which the nft path needs, was absent from the config read here and may be present in current Docker Desktop. That asymmetry is the actual argument: nftables' viability varies by Docker Desktop version in a way nobody here can pin down, iptables' requirement did not vary anywhere it was checked. If nft_fib_ipv4 is present this costs 1.6 MB and nothing else; if it is absent it is the difference between a working full tunnel and none. Rewritten to say that, and to say plainly what is verified versus assumed — this is the third round in which the previous round's central premise did not survive, and a confidently-worded paragraph is what the next round inherits. Also from review: - CLAUDE.md still said "`iptables` is deliberately absent", the opposite of what this PR now does, contradicting the Dockerfile and both other docs. - The Dockerfile referenced "the pia-vpn skill", which does not exist on this branch — the third forward reference of that kind, now gone. - "full tunnels work on native Linux, Mac and WSL2 6.6" was unconditional and contradicted ten lines later by the `DNS =` concession, which stops them on every platform. Reordered so the DNS hurdle is named as the first one. - The WSL2 gap was written as a permanent platform limitation. It is a stale install: `wsl --update` moves the host to a current kernel that has the symbol. That remedy was missing from the user-facing doc. - The migration probe label carried an internal comma, which `joinFeatures` renders into a comma-joined list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:11:17 -07:00
shadow-testandClaude Opus 5	92d64cf252	Ship iptables, not nftables — nftables forfeits macOS ... Re-review overturned the previous commit's package choice, and verifying it proved the reviewer right. `wg-quick` picks nft *unconditionally* when it is present (`type -p nft`, line 241), so installing nftables makes the iptables path unreachable. Its nft ruleset then needs a third expression family the iptables path does not. Isolating the rules on this host, the two connmark rules install fine and this is what fails: nft add rule ... fib saddr type != local drop Error: Could not process rule: No such file or directory That decides it, because of how the hosts differ. LinuxKit's kernel config — Docker Desktop for Mac, identical on x86_64 and aarch64: CONFIG_NETFILTER_XT_CONNMARK=y <- the iptables path works # CONFIG_NFT_FIB_IPV4 is not set <- the nft path does not So nftables would have broken the platform it was added to fix. With iptables, full tunnels work on native Linux, Docker Desktop for Mac, and WSL2 from 6.6. Costs 7,203 kB rather than 5,614 kB on amd64. That also means the mechanism the previous commit documented was wrong: with nftables installed `xt_CONNMARK` is never consulted, and the real blocker on that path is `nft_fib_ipv4`. Rewritten around what actually fails. A second failure neither round had found: `wireguard-tools` only *Suggests* `openresolv | resolvconf`, so neither is installed, and every provider's stock config has a `DNS =` line. That fails in `set_dns()` — before any routing — so it takes split tunnels down too, contradicting what this PR previously claimed: [#] resolvconf -a sp -m 0 -x /usr/bin/wg-quick: line 32: resolvconf: command not found EXIT=127 Not fixed, deliberately: `openresolv` has no installation candidate on noble, and `resolvconf` resolves only by pulling in systemd-resolved — a resolver daemon and systemd units, into a container with no systemd. Documented instead. Smaller corrections from the same review: - the size caveat blamed ~209 kB of libelf1t64; for this package set the real over-count is libelf1t64 + netbase. Restated, and arm64 now given against the real base rather than left as a bare-ubuntu figure. - the manual-install fallback omitted `iproute2`, so it left the user without `ip` — the command the tunnel needs most. - "Without it" had been orphaned from its antecedent by inserted paragraphs and read as referring to configuring a tunnel. - the migration probe said "VPN support", presenting VPN as a feature gained to users who never enabled it. Now names the tools and the toggle. - "What's Inside the Container" gains a row; the key-material-in-snapshot hazard was in CLAUDE.md only, and is the one genuinely user-facing warning here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 16:24:07 -07:00
shadow-testandClaude Opus 5	ab2c75d0b2	Ship a firewall backend, and correct three claims review disproved ... Review of #28 found the iptables exclusion was justified by a false premise, and I confirmed it: `wireguard-tools` declares `Recommends: nftables | iptables`, `--no-install-recommends` strips it, and `wg-quick`'s add_default() shells out to a firewall backend with no `type -p` guard. Measured on the image as this PR shipped it: [#] iptables-restore -n /usr/bin/wg-quick: line 32: iptables-restore: command not found wg-quick EXIT=127 That fires for `AllowedIPs = 0.0.0.0/0` — every stock full-tunnel config from every provider — not for a desktop client's killswitch as the comment claimed. Split tunnels are unaffected. Ship `nftables` rather than `iptables`: wg-quick prefers it (`type -p nft`, so with both installed iptables is dead weight), it is first in the package's own Recommends, and it is half the size. The review's proposed fix stopped there; it does not hold. Adding nftables does not make wg-quick work on this host, and neither does iptables: Warning: Extension CONNMARK revision 0 not supported, missing kernel module? `Table=auto` routes by fwmark and needs xt_CONNMARK from the *host* kernel. WSL2 has none and containers have no /lib/modules to load one from. So this fixes native Linux and Docker Desktop for Mac — which other WHP users are on — and cannot fix Docker Desktop for Windows, where the answer is to add routes with `ip route` directly. Documented rather than left to be rediscovered. Also from review: - "`ip` and `wg` are always present" was false. A project keeps the base image it was first built from, so this reaches new projects only. Reworded to match the wording already used for the Playwright libraries, and `/usr/bin/wg` added to FEATURE_PROBES so an existing project is *told* it is missing VPN tooling and prompted to migrate, rather than finding out via `wg: command not found`. - "no client is installed" contradicted shipping `wg` four lines earlier. The true claim is that no tunnel is configured or started. - The size figure measured against bare ubuntu:24.04, which over-counts by the ~209 kB of libelf1t64 the real base already has, and covered one arch. Now measured against the current base on amd64 and stated for arm64 too, per the standard CLAUDE.md sets for the Playwright layer. - `/run` persistence conflated two mechanisms: same-container files on a stop/start, `docker commit` on a recreation. Both stated, plus the corollary that key material written to /run ends up inside a snapshot image — observed, a `wg.priv` was already sitting in one. - The DNS bullet presented a Docker Desktop address as the general case. Now leads with the mechanism, notes 127.0.0.11 on a user-defined network is unaffected, and adds the two things the advice omitted: a resolver the tunnel can reach (or it leaks every query), and pinning the endpoint via the old gateway (or the tunnel routes through itself). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 13:55:44 -07:00
shadow-testandClaude Opus 5	00937745f7	Ship the tools the VPN toggle grants capability for ... `vpn_support_enabled` hands a project CAP_NET_ADMIN and /dev/net/tun, and the image then contains no `ip` and no `wg` — a capability with nothing able to exercise it. Bake `iproute2` and `wireguard-tools` (~4.3 MB with deps). They belong in the image rather than a runtime install for the reason the Dockerfile already gives for the Playwright libraries: the writable layer is lost on base-image migration. A hand-installed `wg` works until an upgrade and then vanishes, which presents as a tunnel that will not come up rather than as a missing package. One project only had `ip` at all because MariaDB pulled in iproute2 as a transitive dependency. `iptables` stays out. Only a desktop client's killswitch wants it, and those clients need a GUI the container cannot provide. Also correct three things the docs left users to discover: - the toggle grants capability and routes nothing, which is being reported as the default network "not routing through the VPN automatically" - no tunnel survives a restart, and `/run` state riding the snapshot makes it look as though one did while traffic goes out the real address - a full tunnel captures the Docker resolver, which sits outside the container's subnet, and takes DNS down with it — Claude Code then reports a connection failure because it cannot resolve api.anthropic.com, and a health check aimed at an IP literal passes throughout Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 12:38:37 -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	fa4940dd7d	Say when a scheduled task is running ... A run is detached — cron has no terminal, and the app fires it as a detached exec — so triggering one and watching the log was indistinguishable from triggering one that died. Worse, `claude -p` writes its answer in a single burst at the end, so a healthy run shows nothing but its log header for as long as it is thinking. The honest reading of the old UI was "it stalled". triple-c-task-runner now publishes a state file per run (pid, start time, log path) and removes it from an EXIT trap. flock remains what actually prevents overlapping runs; this is purely observability, so every reader verifies the pid rather than trusting the file — a container stopped mid-run cannot fire a trap, and a task stuck on "running" forever would be a worse lie than no indicator at all. Stale files are cleared on read. On top of that: - `list` grows a status column: "running 4m12s" or "idle". - `status [--id] [--watch]` answers "is it still going?" directly, with elapsed time and the tail of the log when there is any output yet. - `run` streams the log instead of blocking silently, and refuses to start a task that is already running. - The Automation tab marks a running task, disables its Run now button, and polls while anything is in flight — including the second or two between firing a run and the runner registering it, which is the exact window that used to read as dead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 06:33:49 -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
shadow-test	77567ac2ae	Merge remote-tracking branch 'origin/main' into feature/corporate-ca ... # Conflicts: # app/src/lib/tauri-commands.ts	2026-08-10 11:20:23 -07:00
shadow-testandClaude Opus 5	4fdfed7955	Bake the browser's runtime libraries into the base image ... `npx playwright install chromium` downloaded ~150 MB of browser that then died with "error while loading shared libraries: libglib-2.0.so.0" — verified, not inferred, against the current image. The image shipped none of Chromium's shared libraries, which is why `apt install google-chrome-stable` looked like the cure: apt was quietly installing the same set as Chrome's own dependencies. Installing them at runtime instead converges on the worst possible state. The libraries land in the container's writable layer, so they are re-paid after every Reset and *lost* on base-image migration, which replays apt from a manifest. The browsers ride in ~/.cache/ms-playwright, inside the home volume, and survive both — leaving a 400 MB browser present with its libraries gone. So the libraries are baked and the browsers are not: each half now lives where it already persists. The layer runs `npx --yes playwright@latest install-deps chromium` rather than a hand-written apt list. Ubuntu 24.04's 64-bit-time_t transition renamed a swathe of these packages (libasound2t64, libatk1.0-0t64, libglib2.0-0t64, …) and a new Chromium dependency would drift straight back into the launch failure this exists to prevent; letting Playwright name its own dependencies is self-maintaining. It sits immediately after Node — npx is its only prerequisite — and well above the shim COPYs, so editing a shim does not re-run it. The `--dry-run` that follows is a build-time assertion, not decoration: on a platform Playwright has no list for, `install-deps` prints a warning and returns having installed **nothing, with exit status 0**. Without the assertion that ships a broken image behind a clean build log. Measured, on a build of this file with the layer applied over an otherwise identical image: +99 packages, +334 MiB unpacked and +119 MiB compressed (2950 → 3284 MiB, 759 → 878 MiB). Two thirds of that is not reachable by trimming — libgbm1, which Chromium needs, pulls mesa-libgallium, which pulls libllvm20. A chromium-only apt list measures 247 MiB against install-deps' 341 MiB; the ~94 MiB difference is xvfb and the CJK/emoji fonts, kept because the base ships no fonts at all and every page this feature exists to display would otherwise render as tofu. Verified on real builds, both architectures: a `--platform linux/arm64` build of this file installs the same 99 packages and passes the same assertion. On the new amd64 image, `playwright install chromium` with no `--with-deps` and no `install-deps` launches headless Chromium 151.0.7922.34 and loads a page; on the old image the identical script fails on libglib-2.0.so.0. `install.rs` no longer runs `install-deps` unconditionally — that would be a minutes-long apt run for nothing on a current image. It asks `install-deps --dry-run` first and skips the install when everything is present, saying which of the two happened on the progress stream. The check is Playwright's rather than a probe of our own for library names, so check and fix cannot disagree about what the dependency set is. Note that `--dry-run` exits 0 both when everything is installed and when Playwright has no list for the platform, so the verdict is read from its output. Containers on older images stay the normal case until people migrate, and they still work: on such an image the simulation cannot even resolve the package names (the index is cleaned in every base image), which reports as "couldn't tell" and installs — the right answer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k	2026-08-10 10:57:21 -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	7d00390e1f	Add scheduled task creation, and stop a bad cron unscheduling everything ... Completes the Automation tab: it could list, toggle, run, log and remove tasks but not create them, so task creation still meant dropping to the CLI. Adds add_scheduled_task and update_scheduled_task, plus a task editor with cron presets and a plain-English reading of the expression. Every field is free user text, so all of it goes to the scheduler as a bare argv vector through bollard — no shell, no quoting. Validation is shape-only rather than metacharacter scrubbing: length caps, no control characters in single-line fields, no leading-dash name, absolute working_dir. Verified by round-tripping a prompt containing `; rm -rf /`, `$(id)`, backticks and newlines: it landed byte-for-byte in the task JSON with nothing executed. The scheduler CLI has no `edit`, so update is add-then-remove with the add first — a rejected edit leaves the original intact. The new id is surfaced in the editor rather than hidden. Root-cause fix, and the more serious half of this commit: triple-c-scheduler never validated --schedule, and rebuild_crontab regenerates the entire crontab and pipes it to `crontab`, which rejects the whole file if any line is malformed — with the error thrown away by `2>/dev/null || true`. A single bad schedule therefore silently unscheduled every other task in the container while reporting success. Reproduced directly. It matters because the global CLAUDE.md tells Claude to drive this CLI, so Claude could trigger it unprompted. `add` now validates the expression and exits non-zero, and rebuild_crontab reports a rejected crontab instead of swallowing it, keeping the offending file for inspection. Verified against the real CLI in this container: a bad schedule is refused without disturbing an existing task's crontab entry, and `0 9 * * 1-5`, `*/30 * * * *`, `0,30 8-17 * * *` and `0 0 1 1 *` are all still accepted. The Rust layer validates independently, agreeing with vixie cron on 23 probed expressions including `1/2` and `*/0` being invalid. 121 frontend tests, 44 Rust tests, both builds clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 12:20:52 -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.7	7840bddbb4	Sync bundled mission-control to upstream 15fbc94 ... Pulls in 15 upstream commits since the April 3 bundling snapshot (msieurthenardier/mission-control). Notable changes: - agentic-workflow rewritten as the "fast" variant: per-leg design and implement, single review and commit across the whole flight - New Skill-Project Boundary section: skills no longer read or write project-owned artifacts by literal heading - routine-maintenance scoped to post-mission only; adds state-machine reachability and cache freshness audits - Test metrics capture threaded through debrief, maintenance, and flight - Crew prompts no longer carry skill-required instructions; SKILL.md is the protocol - Worktree git strategy removed; standardized on {target-project} - Jira artifact template removed upstream Local URL correction in init-project/README.md preserved (anthropics/flight-control -> msieurthenardier/mission-control). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 08:10:32 -07:00
shadow-testandClaude Opus 4.7	5974347913	Add per-project sandbox mode and Bedrock service-tier ... Sandbox mode: new per-project toggle that turns on Claude Code's bash sandbox inside the container. Adds `bubblewrap` and `socat` to the Dockerfile (the two Linux deps required by the sandbox), and emits a managed `sandbox` block into `~/.claude/settings.json` via the existing CLAUDE_CODE_SETTINGS_JSON entrypoint merge: - `enabled` mirrors the Triple-C toggle and is always emitted, so the entrypoint's recursive jq merge clears any prior on-state from the persisted named volume — Triple-C is authoritative. - `enableWeakerNestedSandbox: true` because we run inside Docker without privileged user namespaces. - `allowUnsandboxedCommands: false` to disable the `dangerouslyDisableSandbox` escape hatch — opting into the sandbox shouldn't come with a runtime bypass. When sandbox is on, a SANDBOX_INSTRUCTIONS section is appended to CLAUDE_INSTRUCTIONS so Claude can guide users through allowing extra paths/domains, excluding `docker *`/`watchman *` from the sandbox, and the rule that `sandbox.enabled` is owned by Triple-C. The Claude-Code settings fingerprint includes sandbox state (only when on, to avoid spuriously flagging existing containers for recreation on upgrade). Bedrock service tier: new optional field on the per-project Bedrock config. When set, exported as ANTHROPIC_BEDROCK_SERVICE_TIER (added in Claude Code 2.1.122) and included in the Bedrock fingerprint. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-01 12:58:54 -07:00
shadow-testandClaude Opus 4.7	de1d809de5	Update Flight Control reference URL to mission-control repo ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-16 15:45:29 -07:00
shadow-testandClaude Opus 4.6	ddf44d97e5	Fix Docker build: manual NodeSource setup + retry loops on all apt-get updates ... The previous fix wasn't enough: the NodeSource setup_22.x script runs its own internal `apt-get update` without retries. When that hit the Ubuntu mirror-sync issue (stale Packages.gz with mismatched hash), the script silently bailed without configuring the NodeSource repo. The next `apt-get install -y nodejs` then installed Ubuntu's default nodejs 18, which ships without npm, breaking the `npm install -g pnpm` step. Changes: - Replace the `curl ... | bash -` NodeSource setup with manual GPG key + repo file configuration, giving us direct control over apt-get update retries. - Add the same 5-attempt retry loop (with 10s sleep and lists cleanup) to the Python 3 and Docker CLI steps, since both also do an apt-get update and would hit the same failure mode. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-16 09:50:42 -07:00
shadow-testandClaude Opus 4.6	d60124f1bd	Fix CI: harden version computation and Dockerfile apt retries ... Two fixes for the v0.3.x initial build failures: 1. **Compute Version step**: When no tags match v0.3.*, `grep` returns exit 1 which under `pipefail` killed the step before the empty-tag fallback could run. Added `|| true` to the pipeline so the fallback (`git rev-list --count HEAD`) runs correctly on first 0.3.x build. 2. **Dockerfile apt-get update**: Transient archive.ubuntu.com mirror sync failures (stale Packages.gz with mismatched hash) broke the GitHub CLI install step. Added a shell retry loop (5 attempts with 10s sleep, clearing /var/lib/apt/lists/* between retries) to both the main system packages step and the GitHub CLI step, plus Acquire::Retries=3 on the other apt-get update calls for transient network failures. Also includes the Cargo.lock 0.2.0 → 0.3.0 rev that went with the previous version bump commit. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-16 09:09:30 -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	86176d8830	feat: add voice mode support via mic passthrough to container ... Enables Claude Code's /voice command inside Docker containers by capturing microphone audio in the Tauri webview and streaming it into the container via a FIFO pipe. Container: fake rec/arecord shims read PCM from a FIFO instead of a real mic. Audio bridge exec writes PCM from Tauri into the FIFO. Frontend: getUserMedia() + AudioWorklet captures 16kHz mono PCM and streams it to the container via invoke("send_audio_data"). UI: "Mic Off/On" toggle button in the terminal view. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-05 06:11:33 -08:00
shadow-testandClaude Opus 4.6	58a10c65e9	feat: add OSC 52 clipboard support for container-to-host copy ... Programs inside the container (e.g. Claude Code's "hit c to copy") can now write to the host system clipboard. A shell script shim installed as xclip/xsel/pbcopy emits OSC 52 escape sequences, which the xterm.js frontend intercepts and forwards to navigator.clipboard.writeText(). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-05 05:47:42 -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	b566446b75	Trigger multi-arch container build for ARM64 support ... Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-01 17:31:13 -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	854f59a95a	Fix Docker/CI: reproducible Windows build, Dockerfile cleanup ... - Fix Windows CI build to use npm ci instead of deleting lockfile and running npm install, ensuring reproducible cross-platform builds - Remove duplicate uv/ruff root installations from Dockerfile (only need the claude user installations) - Make AWS CLI install architecture-aware using uname -m for arm64 compatibility - Remove unused SiblingContainers component (dead code) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-28 20:43:14 +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	ca51e73924	Add AWS Bedrock auth mode with per-project configuration ... Introduces a third auth mode alongside Login and API Key, allowing projects to authenticate Claude Code via AWS Bedrock. Includes support for static credentials, profile-based, and bearer-token auth methods with full UI controls. Also adds a URL accumulator to the terminal to reassemble long OAuth URLs split across hard newlines, and installs the AWS CLI v2 in the container image. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-27 14:29:40 +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