149 Commits

Include renames

Author	SHA1	Message	Date
shadow-testandClaude Sonnet 5	d8bb5ab262	Address review findings: durability, stale container ids, honest toasts ... An Opus review of the previous commit found several real gaps: - pending_cleanup::save used plain write-temp-then-rename, unlike migration_store's fsync'd write it claimed to mirror — a crash in that window left a truncated record that list() would skip forever, silently reproducing the exact bug this module exists to fix. Now matches migration_store's File::create/write_all/sync_all/rename/sync_dir shape, and the tests exercise the real save/list/clear functions against a temp dir instead of re-implementing their bodies inline. - remove_project and rebuild_project_container only ever looked at project.container_id, unlike every other container-destroying path in the codebase, which falls back to find_existing_container for exactly this race (a crash between creating a container and persisting its id). A miss here left a container that then blocked every subsequent volume removal with a 409, forever. Both now resolve the same way the rest of the codebase does, and record the container by its deterministic name rather than its id so a retry still has something that resolves. - remove_project's toast promised an automatic retry unconditionally, even when writing the pending-cleanup record itself failed (the one case where nothing will actually retry). ProjectRemovalReport now carries retry_scheduled, and the UI is honest about which case it's in. - remove_volumes_by_name now retries once after a short delay on a 409, since Docker releasing a volume's mount reference right after its container is removed is not always instantaneous, and this is exactly the sequence remove_project runs. - rebuild_project_container (Reset) returns ProjectResetOutcome so the UI can warn when Reset could not fully clear a project's volumes, instead of only logging it — the new container silently reuses old data otherwise, which is what Reset promises not to do. - retry_pending_cleanup_logged escalates a record's log level after it has failed for a week, since recorded_at was otherwise write-only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 08:36:27 -07:00
shadow-testandClaude Sonnet 5	4827170715	Report and retry Docker resources remove_project could not delete ... remove_project_volumes always returned Ok(()) regardless of what actually happened, making the `if let Err(e)` guarding it at every call site dead code. remove_project then dropped the project record unconditionally, so a volume, image or container that failed to delete became permanently unreachable — confirmed against a real orphaned volume pair found in the wild (fixes #31). remove_project_volumes/remove_snapshot_image/remove_container now report what they could not remove (treating "already gone" as success rather than a leftover), remove_project surfaces this to the user via a toast, and before dropping the project record it writes a pending-cleanup record that startup housekeeping retries automatically on the next launch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 08:18:41 -07:00
shadow-testandClaude Opus 5	eead748222	Close what two reviews found in the Files tab transfers ... Two independent reviews of 2c9482a, one for correctness and one against the threat model. Between them they found two ways to lose a file, one way for a container to choose a Windows save destination, and a rule that made every dotfile unsavable. Every finding below was demonstrated against a real container before being fixed, and the fixes are demonstrated the same way. ## The download was accepting truncated reads and refusing whole ones The `[ -f ]` bracket around the read was wrong in both directions. It missed the case that loses data. Truncation *in place* — `> file`, log rotation, `tar -x`, most build tools — leaves a regular file behind, so `dd` stopped at the new EOF and exited 0. Measured: a 600 MB source truncated mid-read delivered 34 MB, which was then renamed over the user's own earlier copy and toasted as `Saved (34.1 MB)`. Truncate-to-zero did the same and needs no adversary at all. And it failed *good* downloads. `dd` already holds the fd, and neither `rm` nor `mv` can touch an open one — the bytes are complete. But `rm` makes `[ -f ]` false, so a finished 600 MB transfer of a file a bundler happened to unlink was deleted, reporting "nothing was saved". The comment claiming the bracket caught a "mix of two files" was simply wrong; an open fd cannot be a mix. So the script now measures the file before reading it and puts the answer on stderr, and Rust checks that at least that many bytes arrived. One rule, subsuming everything the bracket was for. Verified against a real container: truncation mid-read and the FIFO race are refused; deletion, rename-over, a growing file, an empty file and an untouched 600 MB read all pass. ## On Windows the container, not the user, was naming the save destination `suggested_save_name` split on `/` only, and it feeds the save dialog's pre-filled name. Backslash is a legal Linux filename character and `validate_container_path` has no reason to object — `..\..\Users\…` is one POSIX segment. The Windows common file dialog parses its name box as a path on Save, so a container-created file called `..\..\..\Users\vic\AppData\Roaming\Microsoft\Word\STARTUP\x.dotm` put its own bytes in an auto-loading Office directory on one un-read click. `resolve_host_path` did not stop it: Word's `STARTUP` and Excel's `XLSTART` are not in the autorun denylist, which this file's own docs already concede is "losing by construction" and was never meant to be the boundary here. The name is now sanitized of every separator, the drive colon and the rest of what NTFS refuses, so it cannot be a path on any platform this ships to. ## No dotfile could be saved, and the app pre-filled the name that guaranteed it The write policy judged the leaf for hiddenness, so `/workspace/.env` was refused *after* the modal and the overwrite prompt — quoting the name the app itself had suggested. `.gitignore`, `.dockerignore`, `.eslintrc.json`, `.nvmrc`: all unsavable, while uploading them worked, so a dotfile could go in and never come out. `HostPathUse` gains a third mode. `WriteChosenName` drops the leaf check and keeps every directory rule, and only `download_container_file` uses it — the dialog is a real boundary for that caller and only that caller. `download_container_backup` still takes its path over IPC as a string and keeps the strict rule. ## Smaller, all found by the reviews * A download had no ceiling. `dd` resolves through the container's `PATH`, which its agent owns with passwordless sudo; a replacement writing forever was measured at ~6 GB/s, so one click on a file listed as 2 KB filled the host disk with no progress shown and no cancel. Bounded now by what the file measured, with slack that is absolute for small files and proportional for large ones, so an honest growing log is unaffected. * "Framed rather than verbatim" did not stop container text reaching the toast headline: `readableRefusal` matches with `includes`, and it has to, because the app's own refusals carry those markers mid-sentence. Anchoring would break them. The fix is at the injection point — container text is clipped to one 200-character line with control characters stripped — plus a `max-h-40` on the toast message, which the `detail` block always had and this half did not. 8 KB of prose in a `z-[60]` card pushed its own dismiss button off-screen. * `savingPath` was a scalar while the design deliberately allows concurrent saves. Starting a second freed the first's row mid-transfer, and whichever finished first cleared both; dismissing the second dialog was enough. It is a `Set` now. * `setUploading(false)` fired when the command settled, not when the refresh finished, so a second click landed mid-relisting. * `upload_files_to_container` checked the container directory before the picker and then used the unresolved path. A modal has no time limit. It re-checks after, which is what `docker::exec`'s doc comment already claimed. * `wait_for_exec_exit` flattened a missing exit code to `Some(0)`, which made the new `!= Some(0)` check unreachable by construction. * `normalize_host_path` did not collapse repeated separators, so the lexical system-root rule was silently absent for `C:\\Windows\…`. Not exploitable — the resolved pass catches it — but a documented layer that does nothing is a trap for the next caller. * README still carried the "no host path crosses IPC in either direction" claim the previous commit narrowed everywhere else, and HOW-TO-USE described the hidden rule without saying it applies to folders only. 480 Rust tests, 602 frontend, no new clippy warnings. Eleven mutations against the new tests, all killed — two of the first round survived and were rewritten: one because `split_whitespace` already handled the case I thought I was testing, one because I had deleted a comment rather than the behaviour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LHL9ty7arp8FHwvE77ne7y	2026-08-25 10:42:26 -07:00
shadow-testandClaude Opus 5	2c9482a67d	Give the Files tab back its uploads and downloads ... `upload_file_to_container` and `download_container_file` existed on main before any of this work started. "Ship the Files tab container-side only" removed them and called it narrowing scope; from a user's side it was a regression they upgraded into. This restores the feature. The reason for the removal was real — four consecutive audits found their criticals in host paths crossing IPC — so the feature comes back only in the shape that removes the class rather than patching it a fifth time. The dialogs are opened by **Rust** (`pick_save_path`, `pick_files_to_upload`), not by the webview. A frontend `open()`/`save()` handing the backend a path string is exactly what failed, and the backend cannot tell such a string from one a compromised webview invented. Now the webview can ask for a picker and that is the whole of its influence: it cannot name a host path as an input. That is the shape the previous round's own notes named as the honest one if this ever returned. None of the machinery the audits condemned returns. No `link(2)` destination reservation, no placeholder rollback, no collision marker: the OS save dialog already asks about overwriting and Docker's extractor overwrites on upload the way `cp` does, so there was nothing left for it to do. Download reuses the sequence `download_container_backup` has been using unchanged — resolve, stream into a partial file beside the destination, rename last — so a failed transfer never touches the file that was already there. Upload reuses the terminal drop's hardened uploader, with the container's uid/gid resolved once per selection rather than once per file. Against a container that is actively hostile rather than merely surprising: * the read is `dd iflag=nonblock`, not `cat`. `[ -f ]` and the `open` after it are two syscalls and the container owns the filesystem in between; a loop swapping the file for a FIFO wins that race, and `cat` then blocks forever with no writer and no timeout anywhere on the path — the `invoke` never settles and a partial is left in the user's directory for good. Verified in a real container that `cat` hangs, that `iflag=nonblock` returns, and that it is byte-identical on a regular file. * the read is bracketed by a second `[ -f ]`, because non-blocking turns that hang into an empty file that would otherwise be renamed over the destination and reported as a successful save. * an *undeterminable* exit code is a failure. Backup catches this class with its `total == 0` check, which download cannot have because an empty file is a legitimate save; without a replacement, a project restarted mid-download renames a truncated partial over the user's file and reports the byte count as if it were whole. * container stderr is capped. Every other reader of container output in the tree is capped for this reason; the two streaming commands were the exception, and stdout was bounded by disk while stderr was bounded by nothing. * the script's refusals are framed rather than used verbatim, so a directory named to look like one of our own sentences cannot become the toast headline through `readableRefusal`. * the partial name is capped at NAME_MAX. A bundler's 230-character content hash is a name that fits its directory and produces a partial name that does not. Also: a non-UTF-8 dialog path is refused by name rather than silently mangled into a different path by U+FFFD substitution; both actions carry in-flight state, so a second click cannot open a second dialog and a slow save is not indistinguishable from a dead button; and the upload's completion message names the directory, since the picker is modal and the user can browse elsewhere while it is open. Not restored: drag-and-drop, in either direction. `drag:allow-start-drag` stays ungranted and `hold/disk-and-dragout` still holds that work. Two bugs the new tests caught while being written: a double-click on "Save to host…" opened the file viewer on top of the save dialog, and an N-file upload made N redundant execs to re-ask `id -u`. Docs that asserted this feature did not and must not exist are corrected — CLAUDE.md, README, HOW-TO-USE, TECHNICAL and the capability threat model. The "no host path crosses IPC" claim is deliberately narrowed to the inbound direction: paths do still travel outward inside error text, canonical ones included, and the reviewed record should not overstate. 600 frontend tests, 473 Rust, no new clippy warnings. Every new test was mutation-checked; four that survived their first mutation were rewritten, including two whose mutations turned out to be unfaithful and one that was blind to a dismissal leaving a row stuck on "Saving…". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LHL9ty7arp8FHwvE77ne7y	2026-08-25 10:00:21 -07:00
shadow-testandClaude Opus 5	88ffb4744a	Cancel the keydown on Shift+Enter, or xterm submits anyway ... The handler returned `false` from xterm's custom key handler and a comment claimed that was enough to stop the bare CR. It is not. `_keyDown` returns the instant the handler says `false` — before it sets `_keyDownHandled` and before it cancels the event — and `_keyPress` then checks that same flag, finds it false, and emits a bare CR for Enter's charCode 13. So the headline feature of this branch did the wrong thing in a real browser: Shift+Enter inserted the newline and then submitted the half-written prompt, now with a stray blank line in it. Arguably worse than before the fix. Reproduced in Chromium and confirmed against the bundled xterm 5.5.0 source. `preventDefault()` is what stops the browser firing keypress at all. Applied at both call sites — the desktop terminal and the web terminal's copy. The test could not have caught this. jsdom never synthesizes the follow-up keypress, so `expect(sent()).not.toContain("\r")` was asserting a property the environment cannot falsify — a test named for a behaviour it could not exercise. It now asserts `defaultPrevented`, which is the mechanism that actually suppresses the keypress and which jsdom can observe. Mutation-checked: removing the `preventDefault()` fails it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 20:47:01 -07:00
shadow-testandClaude Opus 5	016de8f641	Close the blockers from the fifth audit ... Docs and disclosure. HOW-TO-USE.md's settings table still described the pre-fix behaviour — and help_commands.rs fetches that file from GitHub main at runtime, ahead of the embedded copy, so it would have reached every user's Help dialog the moment this merged. The Config tab named three settings that need a base-image update; there are four, and the omitted one (Session recap) is the one that fails *without* the "won't switch off" symptom the warning teaches. Both now also state the cost nobody had written down: changing any of these recreates the container, which commits a layer. Two stale comments that told a reviewer the code was safe when it was not. compute_claude_code_settings_fingerprint still claimed the historical fingerprint is preserved so an upgrade cannot churn every container — carried over from before the widening, false since the format string changed. And capabilities/default.json, which is the reviewed threat model of record, described a "Save to host…" action this branch deletes. Security and correctness. update_settings validated env vars and nothing else, so the *global* default_ssh_key_path — the fallback for every project without an override — took `/` and read-only bind-mounted the host, which entrypoint.sh then copies into the home volume. classify_ mount_source ran canonicalize on the raw string, which resolves a relative path against Triple-C's own cwd, so `.` and `..` were accepted or refused depending on where the app was launched; the daemon then refuses the mount and the project can never start. Its test passed only because its examples did not exist under app/src-tauri. bind_mount_exclusions still derived a path from every row while project_path_mounts had learned to skip unmountable ones, so a legacy row made /workspace/<name> ordinary container content that a migration would then exclude from staging and destroy. The skip is also logged now rather than silently dropping a folder. The terminal's file-in path checked is_dir() but not file type, so a dropped FIFO blocked forever with no timeout — and it is the only route in now. The web terminal labelled sessions from a global set at request time, so two quick opens swapped them; harmless until Shift+Enter became type-dependent, at which point a mislabelled Claude session submitted a half-written prompt. Opened now carries the type. Every ~/.claude.json write goes through one atomic helper. The awsAuthRefresh branches still truncated in place — the same corruption the Shift+Enter block was fixed for twenty lines later, and its own comment said so. Demonstrated: a failed write now leaves the original byte-identical. And the registration test I added yesterday could pass while the property was false: an audit got five real unregistered commands past its exact-string attribute match, and "exactly once" was in its name but not its body. Mutation-checked against all six shapes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 18:45:11 -07:00
shadow-testandClaude Opus 5	4d1a5a2417	Remove list_sibling_containers, which nothing called ... It listed every container on the daemon — including the user's unrelated postgres, mysql and other work — and handed the summaries to the webview. It had a registration, a command, a docker-layer helper, a typed frontend wrapper and a `SiblingContainer` type, and zero call sites. An audit named it as step one of an escalation chain: enumerate the daemon's containers, then point `update_project`'s unvalidated `container_id` at one and read its files through the file-command surface. The second half of that chain is closed now, but a command that exposes the user's unrelated containers and serves no feature is surface with no upside. Found by the registration test added in the previous commit, which is the answer to "why test something the compiler already checks": the compiler is perfectly happy with a command nobody calls. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 17:15:38 -07:00
shadow-test	e9902f0564	Merge branch 'r4/narrow' into ship/core	2026-08-23 17:08:04 -07:00
shadow-test	7488fc5b70	Merge branch 'r4/host' into ship/core	2026-08-23 17:08:04 -07:00
shadow-testandClaude Opus 5	06ccb4d818	Ship the Files tab container-side only ... Four successive audits found the same thing: host filesystem paths crossing IPC is where the criticals in this work live. The most recent one found the `link(2)` upload reservation returning success against a *directory* (linking into it, leaving permanent stray files, and via a symlink-to-directory writing outside the validated write root), failing every upload permanently on any filesystem without hard links, and the post-resolution credential check weakened from a general rule to an eleven-name denylist. Rather than fix that a fifth time, the Files tab ships as what it is good at: a browser, viewer and renamer that never touches the host. Removed: `upload_file_to_container`, `download_container_file`, and everything that existed only for them — the whole reservation (`UPLOAD_RESERVATION_SCRIPT`, `reserve_upload_destination`, the placeholder rollback, `exec_oneshot_as_within` which had no other caller), `stream_container_file_to_host`, `ChannelReader`, `save_to_host`, the download ceiling, and the collision marker with its frontend contract. On the frontend: the upload button, the pane's `onDragDropEvent` handler, both "Save to host…" affordances, `uploadPaths` / `downloadFile` / the overwrite prompt, and `OverwriteConfirmModal`. `lib/uploadErrors.ts` is now `lib/refusalText.ts` and keeps only the half that turns any backend refusal into the sentence a person reads. Kept, and not weakened: `upload_host_file_to_terminal` and `download_container_backup`. They predate this work, their hardening is a real improvement over main, and they are now the whole answer to "how do I get a file in or out" — drop it on the Terminal, or Back up container. The drop gate (`lib/dropTarget.ts`, `PaneVisibility`) is untouched. `resolve_host_path` gets the general hidden-component rule back. Round 3 replaced it with `HOST_CREDENTIAL_DIRS`, which is allow-by-omission for the rest of `$HOME`: `~/.local/bin` (write there and you own the user's next shell command), `~/.password-store`, browser profiles and `~/.pki/nssdb` were all reachable through a planted symlink with a visible name — verified against a real home directory, and all five refused now. It over-catches `.pnpm` and `~/.cache`; for two occasional callers that is the cheaper mistake, and the refusal says which folder it resolved through. Two defects fixed while in here: * A symlinked directory listed as empty. `find` defaults to `-P`, which does not follow a symlink even as the starting point, so `-mindepth 1` discarded the only match and a real directory rendered as "Empty directory" — a first-order defect now that browsing *is* the feature. `-H` follows the starting point and nothing else, so a loop is `ELOOP` rather than a walk that does not end; verified against a live container for a symlinked directory, a broken link and a loop. `find`'s errno for the loop case is now a sentence. * `finish_download`'s replace path fired on *any* rename failure with a destination present — a vanished partial, a permission error, a directory at the destination — and deleted the user's file to complete a move that could not complete. It is now fenced to Windows (where a rename onto an existing path genuinely fails) and to a partial that still exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 17:05:56 -07:00
shadow-testandClaude Opus 5	9472cb3c4c	Resolve host paths before mounting them, and stop reading stored data as choice ... Four fixes that share a shape: a value already on disk, or one spelled around a check, being taken at face value. `/..` bind-mounted the entire host filesystem read-write. `is_filesystem_root` was purely lexical — trim trailing separators, refuse what was left only if it was empty or a bare `C:` — and nothing in the file ever called `canonicalize`, so `/..`, `/./`, `/home/..`, `/etc/../` and `C:\..` all passed. The daemon resolves them: `docker run -v /..:/mnt/probe` mounts the host root, and the app mounts read-*write* into a container whose agent has passwordless sudo. It is the escalation `check_mount_name_stays_under_workspace` exists to close, reached through the host-path half of the mount instead of the mount-name half. `classify_mount_source` replaces it and asks the OS: `canonicalize` applies `..`, follows symlinks, and resolves 8.3 aliases and UNC spellings on Windows. A path that cannot be resolved — `projects.json` synced from another machine, a folder not created yet — falls back to a lexical collapse rather than being refused, because refusing would make such a project unsavable; the gap is bounded, since what resolution adds is a property of paths that exist. A path that names no location at all (`C:x`, a relative path) is refused rather than guessed at. Same check now guards `ssh_key_path` and `ca_cert_path`, whose read-only mounts were whole-host disclosure at /tmp/.host-ssh. Custom env var names had no charset check anywhere, so `BASH_FUNC_stat%%` — bash's wire format for an exported shell function, body in the value — reached the container environment verbatim. Latent today because the image's /bin/sh is dash, but the pre-commit scrub runs `/bin/sh -c` as root and nothing pins that. Keys are now shell identifiers, on the project and the global list both, with the same grandfathering the folder rows get: a stored key is admitted, a new or edited one is not. The blank workspace row was persisted. The comment said it was dropped on save; the code computed the filtered list and then saved the unfiltered one, so "+ Add folder" plus a blur stored `{"Target": "/workspace/", "Source": ""}` and the project could never be started or recreated again. Every save in the section now goes through one filter, and a blur that changed nothing saves nothing. Widening the five `ClaudeCodeSettings` booleans to `Option<bool>` reinterpreted every stored record. They were plain `bool`s that always serialised, so every project ever saved carries an explicit `"env_scrub": false` that nobody chose — and under the new merge that `Some(false)` beats a global `Some(true)`, where the old rule let the global win. Upgrading silently turned five settings off, "strip credentials from subprocess environments" among them. Deserialisation now goes through a shim that dates the record by the presence of the pre-widening `enable_session_recap` key and reads its `false`s as unset. The fields skip serialising when unset, so an older binary can still parse `projects.json` after a downgrade — a `null` would fail to parse and take the whole list down, since `ProjectsStore` parses all-or-nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 17:02:03 -07:00
shadow-testandClaude Opus 5	dd23a52b41	Fix four upgrade-path defects the coherence audit found ... The ~/.claude.json write was `printf ... > "$CLAUDE_JSON"`, which truncates before it writes. A write that fails part-way — a full home volume, which is the exact condition half this release exists to prevent — leaves the file unparseable, and it never self-heals: the next start's jq fails on the corrupt file, MERGED is empty, and the guard skips the write that would have repaired it. That file holds the OAuth account, so the failure mode is a permanently lost login, in service of a cosmetic flag that suppresses a tip. Demonstrated: old pattern loses the credential, new tmp+rename leaves the original intact. The correct pattern was already in triple-c-task-runner. The web terminal scoped its xterm key handler to Claude sessions but not its mobile input bar or its dedicated newline button, so both sent ESC+CR into `bash -l`, where readline has no binding for it. Silent no-op, and worse from a button that stays on screen looking live. Both now consult the active session's type, and the button is disabled with a reason on a shell tab. The Config tab claimed "Off overrides a global On" without qualification. True for the env-var-driven settings, false for TUI mode, Effort level and Focus mode, whose off state is *removing* a key — an older base image's entrypoint ignores the instruction to remove it. The copy now says so and points at the base-image update. HOW-TO-USE.md said there is no add-task form; AutomationTab renders a "New task" button. That file is fetched from GitHub at runtime by help_commands.rs, so the error was live in every user's Help dialog. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 16:45:20 -07:00
shadow-test	47960e46df	Merge branch 'r3/drop' into ship/core	2026-08-23 15:48:19 -07:00
shadow-testandClaude Opus 5	39934299f9	Stop the snapshot retry being an unconfirmed revoke, and unbrick legacy configs ... Three things, all reachable from a single credential-handling round. **The "Retry snapshot cleanup" button deleted the token.** `clear_claude_token` called `secure::delete_claude_oauth_token()` unconditionally; the `mode` argument only changed the toast wording, so there was no sweep-only path on the wire. The leftover panel rendered on `leftover !== null` alone and `onAuthenticated` never cleared it, so the sequence revoke -> snapshot skipped -> re-authenticate from the button directly above -> press the retry the panel is still offering threw away the token acquired seconds earlier, announced by a message about images. The deliberate Revoke needs a confirmation modal; this needed nothing. `sweep_claude_token_snapshots` is the honest primitive: it rewrites the images and never touches the keychain. The images are the durable record, so the retry re-derives its work from Docker and needs no stored token. Re-authenticating now clears the panel, and the Authenticate button is disabled while a cleanup runs — a sweep is a per-image inspect/create/commit/rmi over the Docker socket and takes minutes. **Sweep-first left the token live for that whole window.** The keychain delete sat behind `list_images` plus the per-image loop, at bollard's 120s-per-request default, while the UI said "Revoking...". A quit or crash in there and nothing was revoked at all; worse, `has_claude_token` stayed true and `shared_claude_auth` reads the keychain at container-*create* time, so a project whose `SecretScrub` guard had already released could be started later in the same sweep and be handed a fresh copy of the credential in its env. Keychain-first now, and the comment that claimed "no window in which a scrubbed image is re-poisoned" — true of images, silent about containers — is corrected. The reorder's original justification (crash-mid-sweep recoverability) is what the sweep-only command covers. A keychain refusal no longer discards a scrub report, because nothing has been swept yet, and both remedies stay on screen: Revoke, and the image sweep, which is now offered in every state rather than only when nothing is stored. **`update_project` validating every folder list bricked existing projects.** It validated nothing until recently while `WorkspaceSection` saved `{paths}` on every blur, so `projects.json` can hold a half-filled row, a mount name with a space, a duplicate, or `/` as a host path. Any such project became entirely unsavable — every Config toggle, every permission-mode change and `useTerminal.ts`'s tab rename came back with a message about folders — and refusing the save did not unmount anything. `validate_project_paths_update` admits a row carried over verbatim from what is stored and holds a new or edited row to every rule, which keeps the escalation closed: introducing a bad value through this command is exactly what a non-carried-over row is. The `/workspace/../tmp/claude-x` chain is the one exception and runs on every row regardless, because a stored one is live data loss rather than untidy data. `ssh_key_path` and `ca_cert_path` had no check at all; a filesystem root there read-only bind-mounts the whole host at /tmp/.host-ssh. Refused on change, with the same grandfathering. Tests are mutation-checked: reverting to sweep-first fails all four new Rust ordering tests, pointing the retry back at `clear_claude_token` fails five frontend tests, and validating an update in isolation fails the legacy-data tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 15:42:20 -07:00
shadowdaoandClaude Opus 5	f7db4323be	Make the drop gate a state question, not a geometry one ... The gate that decides whether a native file drop is accepted has been wrong twice in opposite directions, both times because it tried to be precise about *which points* a dialog covers: - Round 1 asked `el.contains(elementFromPoint(x, y))` and was handed the inner xterm host while the overlays are siblings, so the always-rendered Following/Paused button made the terminal's top-right corner permanently refuse drops. - Round 2 replaced that with "is a blocking overlay painted here?" and deleted the document-wide gate. `elementFromPoint` returns the *topmost* element, and ToastHost is z-[60] against the Modal backdrop's z-50 in the same stacking context — so a refused drop pushed a toast, the toast covered the dialog, and the next drop released on it was reported clear and landed in the directory the dialog was covering. The gate armed its own hole. Split the two questions instead of merging them: - Geometry answers *whose* drop it is (rect hit test, unchanged), so exactly one listener speaks for a drop and a hidden pane's zero-size rect still keeps TerminalView and FilesTab from both firing. - `dropIsBlocked` answers whether the app should take a drop at all — document-wide, no z-index in it. While a modal or blocking overlay is on screen anywhere, every drop is refused. There is no `elementFromPoint` call left, so no future overlay can become a drop hole by being painted high enough and no chrome can become a dead zone by being painted at all. The cost is over-refusal while a dialog is open, in a state the user entered deliberately, announced, writing nothing. Also: - `[aria-hidden="true"]` no longer disqualifies a blocker. It is not a visibility statement (it sits on visible decorative content), so a blocker nested in such a wrapper would have silently stopped blocking. - Modal drops `data-blocks-drop` when its pane hides, and moves focus out of itself rather than leaving it inside a `display:none` panel. - The refusal notice stays `kind: "info"` (an expected refusal is not an error, and an error card never auto-dismisses) and carries a `dedupeKey`, so repeated refusals replace rather than stack. Tests: mutation-checked against the previous implementation — four in dropTarget.test.ts, two in each of TerminalView/FilesTab, two in Modal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 15:31:13 -07:00
shadow-testandClaude Opus 5	ed91423666	Hold back the Disk panel and OS drag-out from the ship branch ... This is a scope reduction, not an abandonment. Both subsystems are preserved in full on `hold/disk-and-dragout` and are intended to come back once they have been hardened separately. Nothing here is a judgement that the features are unwanted — three successive audit-and-fix cycles each closed a critical defect in these two areas and each opened a new one, so the rest of the round ships now and these two get their own cycle rather than holding it up. Removed: the Disk settings panel and its whole reclaim / destroy / compaction surface — `DiskSettings`, `DiskProjectTable`, `useDiskUsage`, `docker/disk.rs`, `disk_tests.rs`, the disk commands in `docker_commands.rs`, and their `generate_handler!` entries. Dropping the IPC entries is the point: a UI-only removal would have left five commands callable by a compromised webview, one of them a verified arbitrary-DELETE primitive. `sweep_orphaned_snapshots`'s *command* goes with them (the panel was its only caller); the sweep itself stays. Removed: OS drag-out from the Files tab — `stage_container_file_for_drag` and its host staging lifecycle, the pointer gesture and `dragPreview`, `stageForDrag` / `isStagedHostPath`, the `tauri-plugin-drag` and `@crabnebula/tauri-plugin-drag` dependencies, and the `drag:allow-start-drag` capability grant, which could not be scoped. The capability test's expected list is updated; its `*:default` and `store:*` assertions are untouched. Kept, deliberately: drag-and-drop *into* the app (Files pane and terminal) and "Save to host…", which is now the only route out of a container. The prevention work is untouched — the pre-commit scrub and `SNAPSHOT_SCRUB_PATHS`, capped container logs, the `triple-c.base` / `triple-c.managed` labels, `sweep_orphaned_snapshots` and the startup housekeeping, the migration pin/probe reapers, scheduler log pruning, `formatBytes.ts`, and `project_lock.rs` in full with every acquisition site outside `disk.rs`. Entanglements, resolved rather than deleted blind: * `container.rs`'s `a_compaction_runs_this_module_s_scrub_script_byte_for_byte` pinned the compaction Dockerfile against `snapshot_scrub_script()`. Dropped — it existed only for compaction. `snapshot_scrub_script` and its containment tests are untouched. * `lib.rs`'s startup reap of `:compacting` tags and `triple-c-compact-*` containers is dropped: nothing on this branch creates them. * `project_lock`'s `Compaction` / `CacheClear` variants and `any_held_excluding`, `migration_commands::is_migrating`, and `formatBytes{Delta,Ceiling}` lose their last production caller but are kept and still tested, annotated with why. * `projects_store::corrupt_since` and `migration_store::peek_ownerless_since` were read only by the disk survey and are removed. The corrupt-load marker and `.bak` are still written. Verified: `npm run test` 611 passing, `npx tsc --noEmit` clean, `npm run build` green; `cargo test` 419 passed / 2 ignored, `cargo build` 0 warnings. Every test removed belongs to a removed feature — no kept-behaviour test was weakened or deleted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 15:20:22 -07:00
shadow-testandClaude Opus 5	6a8972980d	Stop an untouched secret field from deleting the stored credential ... Making `null` actually clear a secret — which it had to, since a blanked token was previously never revoked — turned the config editors into a credential shredder. Secrets are `#[serde(skip_serializing)]`, so the inputs always render empty whether or not one is stored, and the blur handlers sent `value || null` unconditionally. Focusing the Git token field and tabbing away deleted it, with nothing shown and no undo. `useSecretField` encodes the rule: only a field the user typed in may speak about a secret. Untouched, `patch()` contributes no key at all, and Rust already distinguishes an absent key from an explicit null. `withoutUntouchedSecrets` covers the structural half. `saveBedrock` spreads `{ ...bedrock, ...patch }`, and when that falls back to DEFAULT_BEDROCK_CONFIG the literal spells every secret out as `null` — so editing the AWS region would have wiped the credentials as a side effect. Also here: `WorkspaceSection` no longer saves a half-filled folder row, which `update_project`'s new validation would refuse on every keystroke between the two inputs; `snapshots_skipped` is declared on the wire type rather than widened locally; and `#[must_use]` on `ProjectGuard` and `ScrubOutcome` — which immediately caught the migration path discarding its scrub outcome, the one scrub whose silence is expensive because the layer it declined to clean is about to be committed. The capability test reads the real file and is mutation-verified: adding `core:default` back makes it fail. That grant pulls in an unscoped `std::fs::read` of any host path and went unnoticed for months, because nothing in the suite read the file at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 13:23:00 -07:00
shadow-test	7bbb699e4e	Merge branch 'r2/front' into integration/round-1	2026-08-23 13:15:02 -07:00
shadow-testandClaude Opus 5	e70a40507c	Stop granting an unscoped host-file read, and make a refused credential scrub recoverable ... `core:default` was an alias for nine core plugins' default sets, and one of them — `core:image:default` — carries `allow-from-path`, whose handler is a bare `std::fs::read(path)` with no scope mechanism at all. Nothing imports `@tauri-apps/api/image`, so the plugin is dropped rather than scoped; there is nothing to scope it with. The capability file now enumerates what `app/src` actually invokes, which is `core:event`'s listen/unlisten and nothing else from core — every emit in this app originates in Rust. `core:menu`, `core:tray`, `core:window`, `core:path`, `core:resources` and the three dead `dialog:` grants go with it. `core:webview:allow-internal-toggle-devtools` stays because Tauri's own injected debug script calls it; both it and the command behind it are `cfg(any(debug_assertions, feature = "devtools"))`, so it is absent from a release bundle. Verified empirically: an unknown identifier fails the build, so every identifier kept is real and the regenerated `gen/schemas/capabilities.json` carries the opener scope verbatim rather than silently dropping it. `opener:allow-open-url` cannot be host-narrowed — the terminal opens links Claude printed inside the container — so what it does and does not buy is recorded instead, including the verified fact that each scope entry's `app` defaults to `Application::Default`, which matches only `with == None` and therefore refuses `openUrl(url, "/bin/sh")`. `clear_claude_token` deleted the keychain entry first and swept the snapshot images second. The sweep runs once and skips a project another operation holds, the deleted entry made `has_claude_token` false, and Revoke rendered only while a token was stored — so a project that happened to be starting during a revoke kept a live ~1-year OAuth token in its snapshot's `Config.Env` permanently, with Reset (which destroys both volumes) as the only remaining remedy. The sweep now runs first, so a crash mid-revoke leaves the app still saying "authenticated" with the same button still able to finish; a busy project is reported as `snapshots_skipped` rather than folded in with images that genuinely cannot be rewritten; and the panel keeps a retry visible independent of token status, plus offers the sweep outright when nothing is stored, because a snapshot committed by an older build carries the token either way. The retry is the same command — it is idempotent, and the images are the durable record. Also: `openai-compatible-api-key` was written but never deleted, so it outlived its project. The key list is now the single definition and an unlisted key is refused outright, so the writer cannot get ahead of the deleter again. `store_or_clear_project_secret` lands here unused on purpose: the editors send a blanked field as `null` and `store_secrets_for_project` skips `None`, so clearing a secret through the UI is impossible today. Its one call site is in `commands/project_commands.rs`, which belongs to another change in this round. No `devCsp` was added. `tauri dev` loads the main document straight from Vite, and Tauri only attaches a CSP to documents it serves itself — the dev server is proxied through `tauri://` only when `PROXY_DEV_SERVER`, which is `cfg!(all(dev, mobile))`. A `devCsp` here would be inert config that reads as protection. The reasoning, and the one place that could set one, are recorded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 13:07:07 -07:00
shadow-testandClaude Opus 5	5926a52ff6	Stop the terminal and Files panes refusing drops onto their own chrome ... The z-order gate added last round asked `el.contains(elementFromPoint(x, y))` — "is the thing painted here mine?" — and was handed `TerminalView`'s inner xterm host while every overlay in that pane is a *sibling* of it. So any point under the pane's own chrome answered "not mine" and the drop was refused, with no message and no log line. The "▼ Following / ▽ Paused" toggle is rendered unconditionally at `absolute top-2 right-4`, and `ToastHost` is `fixed bottom-4 right-4` 24rem wide with error cards that never time out: two corners of the terminal, and one of the Files pane, that could not accept a file for as long as the app was running. It shipped green because jsdom has no `elementFromPoint`, so not one of the 81 drop tests entered that branch. The tests here install one. The question the gate asks is now "is a *blocking overlay* painted here?". Chrome the pane paints over itself is not one; a dialog backdrop is, and `ui/Modal` marks its own backdrop so the element `elementFromPoint` actually returns is the one carrying the marker. `classifyDrop` also separates "aimed at me and swallowed" from "not my drop", so the first gets a toast and a log line and the second stays silent. Three defects around it: - **A dialog now refuses only the points it covers.** `dropIsBlocked` is document-wide and `ui/Modal` portals to `document.body`, so any open dialog refused every drop in the window. The deeper half of that is that a dialog opened in project A really was still on screen after a tab switch — the pane hides itself with a `hidden` class, which a portal does not inherit — so `PaneVisibility` lets `App` tell a `Modal` its pane stepped aside, and a hidden one paints nothing, traps no focus, answers no Escape and blocks no drop while staying mounted with its state intact. - **`devicePixelRatio` is applied on Windows only.** Only wry's WebView2 backend hands over physical pixels; the macOS and GTK ones deliver logical points and `tauri-runtime-wry` does not rescale them. Halving those was survivable while the test was a bare rect and is a refused drop once z-order joins in. Read from the wry/tauri sources, not verified on a HiDPI Mac or GTK box. - **`isFileExistsError` can no longer be forged by a filename.** It matched `fileexists` anywhere in a normalised error, so uploading a host file called `file-exists.txt` turned *any* failure into a collision — and Replace re-invoked the upload with `overwrite: true`. The marker now has to stand alone in the backend's canonical form, or be a whole discriminant value. - **A refused compaction or cache-clear keeps its dialog.** `reclaim` reports refusals inside `Ok`, so "did it throw" read one as success: the dialog closed, the tick list was dropped, and the explanation appeared in the outcome panel several screens above the row that was clicked. The dialog now stays put and renders the backend's own sentence verbatim. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 13:03:57 -07:00
shadow-testandClaude Opus 5	4f6c012071	Make a rollback pin outliving its project visible and deletable ... `survey_rollback_pins` walks images, not projects, and deliberately tolerates an absent project by falling back to the raw id as the display name. Two things then dropped it on the floor: `destroy` called `find_project` before the confirmation check, so it refused such a pin every time, and the per-project table joins destructive items to rows by project_id, where rows come only from projects in the store. The result was a multi-GB `pre-migration-*` image that the scan measured, the panel never rendered, and nothing could remove — in the one screen built to find exactly that. `destroy` takes the same early return `OrphanVolume` already takes, and still validates the tag: `latest` names the project's live snapshot, so the ownerless path must not be a way around that check. The UI grows a bucket for destructive items matching no row, rather than filtering them away. The typed gate already compared against the id via `project_name`; the dialog now says "project id" instead of asking for a project name that no longer exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 12:18:04 -07:00
shadow-testandClaude Opus 5	1768240861	Unstick a project row whose lifecycle command was refused ... Two more pieces of drift from the same merges, both invisible to `tsc`. **A refused Start/Stop/Reset strands the row.** `start`, `stop` and `rebuild` paint an optimistic "starting"/"stopping" so a click moves the row at once. That was safe while the only way these could fail was after the backend had begun changing things. `fix/sec`'s per-project lock ended that: all three now take the lock and are refused *before* any state changes, and `stop` could not fail this way at all before — it took no exclusion. So the optimistic paint has nothing to become, `isTransitioning` disables both Start and Stop, and the only thing that clears it is `reconcileProjectStatuses`, which runs once from `App.tsx` when Docker first appears. Clicking Stop during a compaction left the project unusable until the app was restarted. `withOptimisticStatus` re-reads the authoritative list when the command throws, and falls back to the status that was on screen if even that call fails — two failures in a row must not land on the one state there is no way out of. The error is rethrown unchanged, so the toast is unaffected. Five of the six new tests fail against the previous code; the sixth pins that the optimistic paint still happens on the way in. **Six secrets are typed as if they arrive, and they never do.** `git_token`, the four Bedrock credentials and `OpenAiCompatibleConfig .api_key` are `#[serde(skip_serializing)]` in Rust, so the key is absent from every project the backend returns — reading one gives `undefined`, not the `null` the type promised. Every current reader happens to use `?? ""`, so nothing is broken today; a single `=== null` would have been a branch that silently never ran. They are optional now, which makes that a compile error, and documented as write-only, which is what they are. 669 frontend tests pass, `tsc --noEmit` clean, `npm run build` green. Nothing under `src-tauri/` touched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 12:12:50 -07:00
shadow-testandClaude Opus 5	7e1f8df1ff	Reconcile the frontend with the round-1 backend contracts ... Five backend branches merged and the TypeScript still compiled, because none of this is a type error: a field that arrives `undefined`, a variant nothing emits any more, a prompt whose loop never closes. Six things. **Orphaned volumes are destructive now, not safe.** `ReclaimTarget:: OrphanVolume` is gone from Rust; the object is a `DestructiveTarget:: OrphanVolume { name, project_id }` confirmed against the *volume's* name, there being no project to name. The TS union still listed it under `ReclaimTarget`, and — worse — `DiskProjectTable` keys destructive items off `project_id`, which an orphan's never matches. So the item existed in the plan and appeared nowhere on screen. `DiskSettings` now splits the plan's destructive list and gives orphans their own section with a per-volume `TypedConfirmModal`. The copy says what a `triple-c-claude-config-*` volume actually is — a Claude login credential, every plugin and skill, every transcript that project had — and keeps the sentence explaining that "no matching project" is a lookup against the project list and is never inferred from a project being stopped or having no image, which is the inference that once flagged two live projects. `TypedConfirmModal` grew a `subject` prop: asking a user for "the exact project name" of a volume that has no project is asking for a string that does not exist. **Snapshot and Total reconcile.** `ProjectDiskRow.snapshot_attributed_bytes` is the single figure `snapshot_attribution()` exists to produce. The column rendered `snapshot_above_base_bytes` and fell back to `—` while the Total was `size - shared` regardless — and in that branch `size - shared` is the whole 4.7 GB base image, charged per project and then added again as a base-image row. One field, one rule. The one branch where the figure *is* the whole image says so rather than passing itself off as a share. **The overwrite loop closes.** Traced end to end: a `FILE_EXISTS:` refusal raises the prompt, Replace re-invokes with `overwrite: true`, Skip advances, "…all" answers the rest without asking, and picker and host-drop both reach `uploadFileToContainer` through `uploadPaths`. Two gaps: a second batch's `askOverwrite` overwrote the first's resolver, leaving that batch awaiting an answer no dialog could produce; and the backend's written refusals — a hidden host folder, a path outside the write roots — were passed as a toast `detail`, which `ToastHost` renders as collapsed monospace behind a "Details" button, so the only sentence that explained anything was the part nobody saw. `readableRefusal` promotes it to the headline when a batch failed the same way. **The browser pane's sandbox is pinned.** `allow-same-origin` must stay (the proxy's gate reads `Origin`/`Referer`, and an opaque origin sends `null`); every top-navigation grant and `allow-popups-to-escape-sandbox` must stay absent, and the test names the offending token rather than printing a set diff. **`@tauri-apps/plugin-store` is gone** from `package.json` — its capability grants were removed as a host-file-write primitive and nothing in `app/src` imports it. The lockfile was updated with `--package-lock-only`, deliberately: `node_modules` is a symlink shared with other worktrees and a real install would have pulled it out from under them. Nothing under `src-tauri/` is touched. 663 frontend tests pass (was 635), `tsc --noEmit` clean, `npm run build` green, `cargo test` 446 unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 12:02:34 -07:00
shadow-test	5fba7d6d35	Merge branch 'fix/front' into integration/round-1	2026-08-23 11:46:17 -07:00
shadow-testandClaude Opus 5	092972fe92	security: close capability, CSP and auth-bridge holes ... capabilities/default.json - Drop every `store:*` grant. `@tauri-apps/plugin-store` has no caller in `app/src`, and the plugin's `resolve_store_path` is a `PathBuf::push` against AppData — `push` discards the base for an absolute path, so the grant was an arbitrary host read/write from the webview. - Replace `opener:default` with a scoped `opener:allow-open-url` (http/https only). That drops `reveal_item_in_dir`, which the plugin does not scope-check and nothing here calls, and the unused mailto:/tel: scope. - Record the unscopable `drag:allow-start-drag` residual risk in `description`. tauri.conf.json - Add `form-action 'none'`, `base-uri 'none'`, `object-src 'none'`. `form-action` has no `default-src` fallback, so an injected auto-submitting form was unblocked even though `script-src 'self'` blocks XSS. - Remove the dead `asset:` / `https://asset.localhost` img-src and `data:` font-src grants; `blob:` stays (the file viewer uses it). auth_bridge - The reserved-port set covered only this project's mappings and the two browser-view ranges. It now also covers the gateway, STT and web-terminal host ports (configured value and shipped default, read off the settings models) and every other project's published host port. A container binding container-loopback 4000 / 9876 / 7681 while those services were stopped had that port mirrored onto the host, unauthenticated, within one poll. - Gate the host listener on fetch metadata: refuse a request that is a cross-site sub-resource, allow navigations (the OAuth redirect) and anything without `Sec-Fetch-*`. Non-HTTP connections are classified from their first line and forwarded verbatim. Residual risk is spelled out in the module docs. - Bound the forwards: max concurrent connections per port, a first-byte deadline enforced before any `docker exec` is created, and an idle timeout. browser_view/mod.rs - `pick_viewer_port` reads procfs with `/usr/bin/cat`, not a bare `cat` the container can shim via its writable PATH entry. - Treat port choice as check-then-bind: walk to the next free candidate when the viewer does not come up, instead of failing the start. BrowserTab.tsx - Sandbox the viewer iframe. Container-controlled content could `top.location` the app's webview away. `allow-top-navigation*` and `allow-popups-to-escape-sandbox` are deliberately absent. HelpDialog.tsx - Escape the quote characters in the entity pass and escape captured attribute values. `href="$2"` with `$2` = `[^)]+` let remote GitHub markdown close the attribute and open another, in a document rendered with `dangerouslySetInnerHTML`. web_terminal/terminal.html - SRI hashes plus `crossorigin` on the three jsdelivr bundles and the stylesheet, and a CSP for the page — it is served 0.0.0.0 behind a permissive CORS layer and nothing else gives it one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 11:13:15 -07:00
shadow-testandClaude Opus 5	d6f065a2b6	Fix HIGH and MEDIUM frontend defects ... Files pane - F16: a drag-out released back inside the app no longer re-imports its own staged copy over the container original. An in-flight flag (cleared from the drag plugin's `onEvent` channel, with a watchdog) suppresses the drop and the "Drop files into …" hint, and an exact staged-path filter is the second line of defence — the `path|size|modified` cache could otherwise write a minutes-old snapshot over a file an agent had since rewritten. - F17: a slow upload/rename no longer yanks the user back to the directory the operation started in. Every operation captures its target path and re-lists only if the user is still there; failures go to the toast host either way. - The grid keeps keyboard focus. Roving tabindex (one tab stop, not one per row) plus focus restore after navigation, rename commit/cancel and Escape. - Transient failures now surface in `ToastHost` (z-[60], persistent aria-live) instead of a `role="alert"` 300 rows down a scroller or behind a modal overlay. The inline error is kept only for the listing failure. - `navigate` is sequenced by generation; "Save to host…" sets `busy`. - Grid a11y: column headers, a text affordance for folder vs file, a live region that is mounted empty and announces completion, Label-in-Name fixed. - FileViewerModal: the blob URL is released only once its replacement exists; the preview is a focusable, named, scrollable region. Native drop routing - New `lib/dropTarget.ts`: the hit test now refuses a drop while any `[aria-modal="true"]` dialog or `[data-blocks-drop]` overlay is up, and checks z-order where the environment can answer it. Shared by FilesTab and TerminalView; App's shutdown overlay opts in. Disk - A partially failed reclaim says so in words ("… — 2 of 5 failed"), not by hue alone. - The scan/reclaim race is closed: every mutation retires an in-flight scan, so a scan can no longer repaint a pre-reclaim report plus a clickable plan of objects that are gone. Scan is disabled while working; the status is a live region; a failed destructive action keeps its dialog open and reports there. - The "unknown" layer count gets a screen-reader fallback; `--text-disabled` no longer carries live information. Terminal / OAuth - After the toast is dismissed, a truncated heuristic guess can no longer fill the slot that an exact OSC 8 or relay URL occupied — the detector remembers every exact URL and drops any candidate that is a strict prefix of one. - The prompt is reachable by keyboard: Ctrl+Shift+O jumps to the default action, Escape dismisses, focus returns to the terminal, and auto-dismiss holds off while focus is inside. It deliberately does not steal focus. - UrlToast renders through `ui/Button` and `--shadow-overlay`. Elsewhere - AuthBridgeRow: a pushed `auth-bridge-changed` status always outranks an older awaited toggle result. - The last two ad-hoc byte formatters route through `lib/formatBytes`. Contract for the backend agent: `upload_file_to_container` refusing to overwrite must satisfy `isFileExistsError` in `src/lib/uploadErrors.ts` (marker `FILE_EXISTS`) and accept an `overwrite` argument; the frontend turns that into an `ui/Modal` Replace/Skip prompt rather than a raw error string. Tests: 536 -> 627 passing. `npm run build` and `npx tsc --noEmit` green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 11:11:43 -07:00
shadow-test	0003793abb	Merge branch 'feat/disk-ui' into integration/round-1	2026-08-23 09:51:44 -07:00
shadow-test	2b9bf56f25	Merge branch 'feat/drag-out' into integration/round-1	2026-08-23 09:51:44 -07:00
shadow-testandClaude Opus 5	611f67cca7	Fix what review found in the Disk section ... Safety: - `destroy`'s rollback-pin arm took a tag over IPC and interpolated it straight into an image reference it then removed. `tag: "latest"` named the project's live snapshot, deleted under a dialog saying "rollback pin". It is the one destructive variant carrying a free-form string, so it now goes through `parse_rollback_tag`. - The compaction's scratch container was named `triple-c-scrub-*`, which is what the scrub reclaim bucket hunts and force-removes. A reclaim from a second window would have destroyed the container a running compaction was about to commit. It gets `triple-c-compact-*`, swept at the start of the next compaction rather than from a bucket anything else can fire. - Deleting a home or config volume only refused a *running* container, but a stopped one still pins its volumes — the resting state of every project ever started — so the user typed the project name and met a raw 409. The container is now removed first and `loses` says so. Correctness: - The compaction Dockerfile emitted no `LABEL`, so the flattened intermediate could never match the sweep's `dangling` + `triple-c.managed` filter that three cleanup paths rely on. Verified on Docker 29.7.2 that the label lands on the final stage, the build still yields one layer, and untagging the staging tag after the commit leaves the committed snapshot intact and startable. - `snapshot_commit_layers` silently meant something else when `triple-c.base-image-id` was absent — the normal case for a pre-label project — counting the base's own layers and letting a never-recreated project qualify for compaction. `base_lineage_known` now carries that, the column says "unknown", and the plan does not offer the rewrite. - `destroy` returned a `ReclaimResult` wearing a `ReclaimTarget` that named work it had not done (a home-volume deletion came back as `OrphanVolume`). Split into `target` / `destroyed`, exactly one set. - `formatBytes` ran `toFixed` after the divide loop, so 999,999 rendered as "1000.0 KB" — in the app's only byte formatter, in a panel full of near-boundary sizes. - `is_base_image_reference` split on the first colon, so a registry port ate the repo name. UI: - `snapshot_above_base_bytes: null` — deliberately unmeasurable — rendered as "0 B", the one guessed number in the table. - Layer count was flagged by colour alone; it now says "stacked". - The tick list survived a reclaim, so the same call could be re-fired at objects that no longer existed. The plan is dropped after any action and the panel says the totals predate it. - `setReport` landed before the plan call was awaited, so a plan failure rendered fresh totals above the previous scan's rows. - Both confirmation modals unmounted before awaiting, making the entire busy path dead code during multi-second work. - `buildx du` failures silently showed `docker system df`'s under-reported build-cache figure with no explanation. - Tooltip text reached no assistive tech, so two headers announced as "Help"; hardcoded input id; error-toned glyph in warning-toned panels; `sweepOrphanedSnapshots` and `clearOutcome` had no callers. - Four docstrings claimed things the code did not do, and two tests were named for behaviour they did not assert. Tests: 513 frontend (was 502), 370 Rust (was 365). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 09:51:09 -07:00
shadow-testandClaude Opus 5	77ef2291d7	Add a Disk section: see where the bytes went, and get them back ... Every recreation runs `docker commit`, which stacks a layer and never rewrites one, and 24 conditions in `container_needs_recreation` trigger a recreation. Prevention landed earlier on this branch; this is the half a user can act on. The per-project table leads with the two numbers that explain the mechanism rather than just the total: how many commit layers a snapshot has stacked above its base, and what the container's writable layer will add at the next commit. Backend (`docker/disk.rs`, commands in `docker_commands.rs`): - `get_docker_disk_usage` — one `df()` joined against the project store, behind an explicit Scan button because it walks the whole daemon. - `list_reclaimable` / `reclaim` — classified buckets with measured bytes, planned off the existing report so re-planning costs no second scan. - `destroy_project_disk_object` — one object, typed confirmation. - `sweep_orphaned_snapshots` — exposed, so its report is finally visible. Safety is structural: `reclaim` takes `ReclaimTarget`, which has no variant that can name a live project's data. Destructive work is a separate type reached only through `destroy`. No unfiltered prune is called anywhere, and nothing outside a `triple-c*` name or `triple-c.*` label is touched. Orphan detection subtracts ids from the project store and consults nothing else. From the daemon's side an idle live project and a deleted one are indistinguishable — volumes present, no container, no image — so inferring from container or image absence would offer a live project's credentials and transcripts for deletion. A store that loaded empty from an existing `projects.json` is treated as a failed load, not as "no projects", because `ProjectsStore::new()` recovers from a corrupt file by starting empty. Three things verified against a live Docker 29.7.2 rather than assumed: - Compaction is a two-stage build (`FROM scratch` + `COPY --from`), which keeps every byte inside the daemon; bollard's import buffers a whole image into memory. uid/gid and setuid survive; a 192.6 MB/4-layer synthetic came out 45.7 MB/1 layer. Image config does not survive, so it is replayed via create+commit, which round-trips a multi-line env var that a Dockerfile `ENV` could not. - Flattening breaks base-layer sharing, so the result carries its own copy of the base. Eight of ten real projects had a 0.10–1.32 GB delta over a 4.72 GB shared base — compacting those costs ~4 GB. The bound now subtracts that penalty, such projects are not offered at all, and the run compares unique bytes and abandons a rewrite that would grow. - `docker builder prune` reports `Total:`, not `Total reclaimed space:`, so the first parser scored every prune as freeing nothing. The Windows/WSL2 note is mandatory and its copy lives in Rust beside the tests that pin it: pruning frees space inside `ext4.vhdx`, which never shrinks on its own, so C: does not change until the disk is compacted. Also adds `lib/formatBytes.ts` — the app had four disagreeing copies, and `projects/home/format.ts` and `migrationCopy.ts` now delegate to it with byte-identical output. Base 1000 by default, matching what Docker prints. Tests: 502 frontend (was 453), 365 Rust (was 322). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 09:39:54 -07:00
shadow-testandClaude Opus 5	1c834a0b08	Drag a file out of the Files tab onto the host desktop ... The Files tab could accept a drop but never produce one: getting a file out meant "Save to host…" and a file picker. This adds the other direction. Two constraints shape it. `dragDropEnabled` is on — TerminalView needs it, since the native drag-drop event is the only one carrying dropped file paths — and it blocks HTML5 drag inside the webview, so `draggable` plus `DataTransfer.setData("DownloadURL", …)` was never available. The gesture is therefore pointer events into `tauri-plugin-drag`, the same shape and the same reason as the tab strip's drag. And the file being dragged does not exist on the host at all: it lives in a container, and the OS can only drag a real host path. So a drag-out is a copy first and a drag second. `stage_container_file_for_drag` materialises the file into `<os-temp>/triple-c-drag-out/<session>/<slot>/<name>` through the same `fetch_container_file` the download and the viewer use, keeps the original filename (a dropped `tmp1234` is not a file anyone wants), and caps at the 256 MiB an upload already caps at, naming "Save to host…" in the refusal. The path comes from Tauri's path API rather than `/tmp`, because on Windows it is neither. The staging directory has a lifecycle, because whole files accumulating in the host temp dir would be the disk problem this project just fixed, in a new place: cleared on exit inside the existing teardown (still guarded on the main window), and reaped at startup for whatever a crash left behind. The copy is also an async gap in the middle of a gesture that feels instantaneous, and the OS only adopts a drag while the button is still down. Small files beat the pointer; large ones do not — so the staged path is cached per entry (keyed on size and mtime, so an edited file re-stages) and the pane says the copy is ready and to drag again, which is an instruction rather than an apology because the retry is immediate. A per-file slot keeps `a/notes.txt` and `b/notes.txt` from becoming the same host path. "Save to host…" stays exactly as it was. Drag-out is the enhancement; a platform that refuses `startDrag` says so and points back at it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 09:12:59 -07:00
shadow-testandClaude Opus 5	0a022dfcf0	Let a project turn a globally-enabled Claude Code setting back off ... The six boolean settings were plain `bool`s merged with `if p.x { true } else { g.x }`, so a project could only ever add to the global set. There was no project value that produced `false` — turning a switch off at project level simply fell through to the global value and the control did nothing. Widen them to `Option<bool>`. `None` means "not set at this level": inherit the global on a project, leave Claude Code's own default alone globally. `Some(false)` is a deliberate off and wins outright. The fingerprint now formats with `{:?}` rather than `{}` — `None` and `Some(false)` mean different things, and conflating them would leave the container un-recreated when a project switched from inherit to off. The project editor grows a third "Global" state per switch; the global editor has nothing to inherit from, so it stays a plain toggle and keeps collapsing to null at the default. Its three existing tests passed unchanged and caught a first attempt that rendered unset as off, which would have told every user their session recap was disabled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 09:05:39 -07:00
shadow-test	df6d2f1ca4	Merge branch 'feat/file-manager' into integration/round-1	2026-08-23 08:35:51 -07:00
shadow-test	dacc1157ec	Merge branch 'feat/disk-and-settings' into integration/round-1	2026-08-23 08:35:51 -07:00
shadow-testandClaude Opus 5	dd2894cc60	Stop Docker disk growth, and fix the Claude Code settings that never worked ... Two independent sets of fixes. ## Disk: stop the growth, no UI this round The dangling-snapshot sweep was already correct and was never the leak. The leak is that every `docker commit` **stacks** a layer and nothing compacts one: a file deleted after it has been committed becomes a whiteout, not free bytes. 24 conditions trigger recreation+commit, so changing one settings field costs a multi-gigabyte layer for the life of the project. One project was measured with 14 stacked commit layers, ~5.1 GB above its base. * **Scrub the writable layer before every commit** (`docker/container.rs`, `SNAPSHOT_SCRUB_PATHS` / `scrub_writable_layer`). The one moment those bytes are still free to drop is before the commit that captures them. Measured on one container's 4.48 GB pending layer: 3.0 GB of agent scratchpad under `/tmp/claude-*`, the terminal drag-drop staging area (256 MiB per file, with no `rm` for it anywhere in the repo), a PNG per pasted image, and the apt lists/cache/logs that `browser_view/install.rs` and `triple-c-playwright-heal` leave behind with no `apt-get clean`. A hardcoded list, never a heuristic: `/workspace/{mount_name}` is a host bind mount and nothing here may reach one, and the three `/tmp` globs cannot select the read-only `.host-ca`/`.host-aws` mounts. Failure is a log line — a scrub must never block a snapshot. * **Cap container logs** (`capped_log_config`). There was no `LogConfig` anywhere, so containers ran on the daemon's unbounded `json-file` default. Deliberately *not* wired into `container_needs_recreation`: participating would recreate every project once, and a recreation costs a commit, which is the thing being fixed. Picked up on the next natural recreation. * **Make superseded base images sweepable** (`container/Dockerfile`). It carried no `LABEL` at all, so `orphan_sweep_filters`' `dangling` + `triple-c.managed` pair provably could not match one — ~11.9 GB observed stranded. Stamping `triple-c.managed=true` is the whole fix; the sweep needed no change. `create_container` writes the new `triple-c.base` key explicitly empty, or Docker's label inheritance plus `docker commit` would make every snapshot claim to be a base image. `force: false` stays, and now says why. * **Sweep at startup** (`lib.rs`), not only after recreation: probes first (a probe pins an image the unforced sweep then refuses), pins second, sweep last. `sweep_orphaned_snapshots_logged` exists because all three callers threw the report away — `reclaimed_bytes`, `failed` and `unavailable` included. * **Reap migration leftovers.** `rollback_migration` retagged and orphaned the migrated snapshot with no sweep. Stale `pre-migration-*` pins are now age-reaped by scanning the tag pattern rather than trusting the state file — `migration_store::load` reports an unparseable record as absent, which stranded a 4-12 GB pin nothing could name again; `load` now moves a corrupt record aside so `has_record` is trustworthy. A pin whose migration is still awaiting confirmation is never reaped at any age. The probe container's removal was a plain statement after an await, so a dropped future (an app quit mid-migration) leaked a container pinning a multi-gigabyte image; it is a `Drop` guard now, with `reap_probe_containers` for the case where the process itself dies. * **Prune scheduler logs.** `remove` deleted a task's JSON but never its log directory, and the task runner appended uncapped `claude -p` output. * **Fix the delete copy.** It said "the container, config volume, and stored credentials"; it removes *both* volumes and the snapshot image. No prune UI, and no unfiltered `prune_images`/`prune_volumes` anywhere — the daemon is shared with the user's unrelated work. ## Claude Code settings: two invented keys, one inverted default, one sticky bug Verified against code.claude.com/docs/en/settings-reference.md and env-vars.md. * `effort` -> **`effortLevel`**, the key Claude Code actually reads; the old one was written and silently ignored. `xhigh` added to the dropdown. * `focusMode` -> **`viewMode: "focus"`**. `focusMode` was invented. The real key does exactly what the existing UI hint already described. * **Session recap was inverted.** Claude Code's recap is on by default, so `CLAUDE_CODE_ENABLE_AWAY_SUMMARY=1`-when-enabled was a no-op and the control could never turn the recap *off*. The field is renamed to `session_recap_disabled` rather than reused: reusing the name with the opposite meaning would have read every stored `enable_session_recap: false` — which is every project that never touched the control — as "the user turned this off". * **The stickiness, which is the important one.** Keys were emitted only when non-default, and the entrypoint *merges* into a settings.json on a persisted volume, so switching a setting off omitted its key, the merge preserved the stale on-value, and the setting stayed on until a destructive Reset. The fix already existed in the same file — the sandbox block is emitted unconditionally for exactly this reason — and is now applied to all five keys. A key whose neutral state is *unset* (`tui`, `effortLevel`, `viewMode`, `awaySummaryEnabled`) is emitted as JSON `null` and the entrypoint deletes it, because a stand-in value is not neutral: `tui: "default"` pins the classic renderer where unset lets Claude Code choose, and `viewMode: "default"` overrides the user's own sticky `/focus` choice. * The same stickiness existed, unnoticed, in the **env vars**: `docker commit` bakes container env into the snapshot image, so a `=1` written once rode it forever. All four are now emitted on every create, extracted into `claude_code_env_vars` and unit tested. Two use an empty value for "off" rather than `0`, because they outrank a setting the user can change from inside their own container and Triple-C's default must not overrule a `/config` choice it never asked about. * TUI mode is now a genuine three-way choice (automatic / classic / fullscreen), which the always-emitted key makes both necessary and possible. `merge_claude_code_settings` is untouched by choice: a project-level OFF still cannot override a globally-ON setting. Tests: 364 frontend (+5), 308 Rust (+23), covering the scrub path list and script, log rotation, pin reaping, and that toggling a setting off actually clears a previously-set ON value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 08:35:10 -07:00
shadow-testandClaude Opus 5	22d142c70d	Shift+Enter newline, OAuth URL truncation, and the auth bridge toggle ... Three fixes that all land on the same journey: sign in, paste a prompt, and have the terminal behave the way every other Claude Code host does. Shift+Enter inserts a newline ----------------------------- xterm.js does not consult `shiftKey` for Enter (`Keyboard.ts`, case 13), so Shift+Enter was byte-identical to Enter and submitted the prompt. Both terminals now send `\x1b\r` (ESC+CR) instead, which Claude Code parses as return+meta — the same bytes its own `/terminal-setup` writes into the VS Code, Cursor, Alacritty and Zed keymaps, so this is in-band rather than a guess. Not `\n`: Claude Code accepts it, but a shell would run the line, so the two session types would diverge. Bound in Claude sessions only for that reason. `entrypoint.sh` sets `shiftEnterKeyBindingInstalled` in `~/.claude.json` so the CLI stops printing its "run /terminal-setup" tip. Purely cosmetic — the decoding is unconditional either way. Alt+Enter has always done the same thing (xterm ESC-prefixes on altKey) and was simply never documented. It is now, along with the rest. OAuth login URL truncation -------------------------- Two producers wrote one toast slot, last-writer-wins. The OSC 7777 relay delivers the URL base64-encoded and therefore exact; ~300 ms later the screen-scraper's debounce fired and overwrote it with a truncated guess at the same link — a URL that parses, points at the right host, and authorises nothing. The user is the one who has to notice. Why the scraper truncated: `ANSI_RE` strips OSC sequences wholesale, including the OSC 8 hyperlink whose parameter carries the complete URL. Claude Code slices the *visible* text of that hyperlink to the terminal width while every emission carries the whole URL in its parameter. The backend already knew this (`commands/auth_token_commands.rs`); the frontend did not. - `urlDetector` now reads OSC 8 targets out of the raw buffer before stripping, filtered by a port of `usable_sign_in_link`, and tags every candidate with its provenance. - The prompt slot gained `supersedes`: better provenance always wins, worse never does, and between equals only a candidate that *extends* what is showing may replace it. That last rule is `extendsUrl`, factored out of `pickSignInUrl` rather than copied — same rule, same reason, one implementation. - `flatten` splits on a bare `\r` as well as on `\r?\n`, so a `\r`-repainted TUI frame no longer inflates a line past the width and suppresses a join that should have happened; and the width is now sampled at `feed()` rather than read at `scan()`, so a resize inside the 300 ms debounce cannot reassemble 80-column text against a 120-column rule. Also corrects the comment claiming `acquire_claude_token` enables the auth bridge. It deliberately does not, and the module comment in `auth_token_commands.rs` explains at length why not. The auth bridge toggle ---------------------- `setAuthBridgeEnabled` and `getAuthBridgeStatus` had zero call sites: the Rust was complete, the IPC wrapper shipped, and there was nowhere to click — so the docs told users to "enable the Auth Bridge" for a switch that did not exist. `AuthBridgeRow` is that switch, in Config → Runtime. It deliberately does not go through the tab's stopped-only save: the dedicated command exists so the bridge can be flipped while a login is hanging in a running container, which is the only moment anyone reaches for it. It also subscribes to `auth-bridge-changed`, which the poller has been emitting to nobody — so a host port the bridge could not take was a completely silent failure, indistinguishable from a login that hung. `tunnel.rs` promotes the best-effort `::1` bind failure from debug to a warning recorded on the port. Half-bound is the failure mode that looks like success: the status says bridged, and a client that resolves `localhost` to `::1` without falling back is still refused. Finally, for a recognised Anthropic sign-in URL the toast now leads with "In container" and demotes the host "Open". The callback listener is inside the container, so the container-side browser closes the loop with no host round trip and no auth bridge; the host button stays as the fallback. Ordinary URLs are unchanged. Tests: 402 frontend (was 359), 285 Rust (unchanged). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 08:31:39 -07:00
shadow-testandClaude Opus 5	15e05e2197	Turn the Files tab into a real file manager ... Rename, an in-app viewer for text and images, host-to-container drag and drop, New folder, keyboard operation — plus the pre-existing bugs the new surface would otherwise have been built on top of. New Tauri commands (file_commands.rs, registered in lib.rs): * rename_container_path — `mv -n -- <from> <parent>/<name>` through exec_oneshot_as, so the *exit code* is checked. exec_oneshot discards the status and interleaves stderr into stdout, which would have made a permission failure look like a success. `mv -n` on its own is not enough either: GNU coreutils makes its refusal to clobber silent and exits 0, so an explicit `test -e` on the destination is what turns a name clash into an error the user sees. `mv`'s own words are surfaced, since renames outside /workspace legitimately fail on permissions. The new name is validated in Rust (no `/`, no NUL, not "." / ".." / empty, ≤255 bytes) — it is user text going into argv, and a name with a separator would be a move rather than a rename. * read_container_file — exact bytes via Docker's archive endpoint, returned as base64. Deliberately not exec_oneshot, which runs every chunk through String::from_utf8_lossy and merges stderr, so it would corrupt any non-UTF-8 file and could splice diagnostics into content. Base64 rather than Vec<u8> because Tauri serialises a byte vec as a JSON number array. Capped and truncation-reporting; the caller picks the cap (images get 5 MiB against text's 1 MiB, being the kind that blows a text-sized budget) and Rust clamps it to 8 MiB regardless. * create_container_directory — `mkdir` without -p, so a clash is an error rather than a silent success. Named for its siblings rather than the bare `create_directory` in the brief. The tar-extraction half of download_container_file is now the shared fetch_container_file() both commands use, and it abandons the transfer once a capped read has what it needs. Frontend: * Single click selects, double click opens. Directory navigation moved onto double click too — a single click used to navigate, which made it impossible to select a directory in order to rename it. Rows are now focusable and the table is a real `grid`: Enter opens, F2 renames, arrows walk the rows. No outline suppression; the global :focus-visible ring is what shows focus. * FileViewerModal (built on ui/Modal, the only correct dialog) renders text in a <pre> and images from a revocable blob: URL. tauri.conf.json's img-src had neither `data:` nor `blob:`, so an in-app image was blocked by CSP; `blob:` is added — revocable, and no megabytes of base64 in the DOM. The asset protocol stays disabled. Anything else gets a "Save to host" state instead of a broken preview, decided by extension and then by sniffing the bytes for NUL. * Host drag-and-drop uses Tauri's native onDragDropEvent, mirroring TerminalView: HTML5 ondrop carries no paths and is blocked in the webview on Windows by dragDropEnabled, which the terminal needs. The listener is window-wide, so it routes by hit-testing the payload position (physical pixels, hence the devicePixelRatio divide) against the pane's rect — a hidden pane has a zero-size rect and never matches, which is what keeps this and the terminal's listener apart. enter/over/leave drive a drop highlight. * Per-row Download is now "Save to host…"; directories no longer offer it. Pre-existing bugs fixed: * Uploaded files landed root:root with a 1970 mtime. tar::Header::new_gnu() zeroes uid/gid/mtime and Docker honours the header verbatim, so uploads were not writable by `claude`. All four single-file tar builds now go through build_single_file_tar() with the container user's ids, read from the container because entrypoint.sh remaps them to the host user on Unix and deliberately does not on Windows. * Symlinked directories could not be opened: `find -printf '%y'` reports `l`. The listing now prints `%Y` as well, so is_directory dereferences and a new is_symlink carries what `%y` used to say. The row labels the link. * upload_file_to_container had no size cap and did a synchronous fs::read on an async worker. Now 256 MiB (matching the terminal drop path) with the read and tar build in spawn_blocking, and the host mtime preserved. * A directory passed to upload reached fs::read and produced an opaque "Is a directory". Rejected with an explanation instead — recursive upload is a larger feature than this panel needs. * download_container_file wrote the *first tar entry*, so downloading a directory silently produced a garbage file. Non-regular entries are now an explicit error. Tests: 46 new (33 frontend across FilesTab, useFileManager and filePreview; 12 Rust covering the find-output parser and the rename validator, neither of which had any). 405 frontend / 297 Rust, both green. No drag-out dependency was added — tauri-plugin-drag is not introduced and OS drag-out is not attempted; that stays deferred, with "Save to host…" as the way files leave the container. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc	2026-08-23 08:30:48 -07:00
shadow-testandClaude Opus 5	2b35aa8c16	Explain a missing tun device where the failure actually happens ... Review caught that the device guard was wired to the wrong call. The daemon does not resolve `--device` at create: verified against Docker 29.7, `docker create --device /dev/does-not-exist` succeeds and prints an id, and runc only resolves the device — and validates sysctls — when it builds the container. So on a host with no tun module the create returns fine and `start` fails, which means the explanation never ran and the user saw the raw daemon string naming a path they would go looking for on the wrong machine. The unit tests fed the create-side string straight in, so they confirmed a function no real failure could reach. Move the guard onto `start_container`, covering create as well in case a future daemon checks earlier. It no longer takes `vpn_support_enabled` — `start_container` has a container id and no project, and nothing else in Triple-C ever requests a device, so an error naming /dev/net/tun is unambiguous on its own. The test now uses the daemon's verbatim message via bollard's real Display format. Also from review: * Soften the security claim. Docker does not enable user-namespace remapping by default, so this is a real CAP_NET_ADMIN in the initial user namespace with only the network namespace confining it. It cannot touch host interfaces, but "confers no authority outside the container" was too strong: within its namespace it can set promiscuous mode and add addresses, routes and NAT on the shared docker0 segment, which puts sibling containers — the LiteLLM gateway among them — within ARP-spoofing reach, and it can flush netfilter rules sandbox mode may rely on. Said plainly in the code, CLAUDE.md and HOW-TO-USE. * Drop Tailscale from the list of clients needing this. Its --tun=userspace-networking mode needs neither the capability nor the device, and listing it invites granting NET_ADMIN for nothing. * Say in the toggle's own hint that changing it recreates the container, matching how every other recreation-triggering setting is labelled. The tab's generic "stop the container first" chip does not tell the user what is about to happen. * Add RuntimeSection tests: saves on, saves off explicitly rather than dropping the key, reflects state, is disabled while running, and carries the recreation warning. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-14 08:15:05 -07:00
shadow-testandClaude Opus 5	65a3d4eb29	Let a project's container run a VPN client ... A VPN client installed in a container today starts, runs, and then hangs until its connection times out. Nothing reports an error: a default container has no /dev/net/tun to open and no CAP_NET_ADMIN to add an interface or a route with, and clients surface that as a generic timeout rather than a permissions failure. Add an opt-in per-project "VPN support" switch granting the three things a tunnel needs. They are useless individually, which is why vpn_host_config() defines the set in one place and the tests assert all of it: * CAP_NET_ADMIN — Docker's default bounding set has net_raw but not net_admin, so a client can ping but never connect. * /dev/net/tun — passed through from the host so the kernel's tun module backs it, rather than mknod-ed inside. * net.ipv4.conf.all.src_valid_mark — WireGuard's wg-quick sets this and cannot from inside a container, /proc/sys being read-only, so its handshakes are dropped by reverse-path filtering. Off by default and deliberately opt-in: NET_ADMIN lets anything in the container reconfigure that container's network stack. It is namespaced — no authority over the host's interfaces or any other container. Capabilities and devices are fixed when a container is created, so this is container state and takes the label-and-compare treatment. triple-c.vpn-support is written unconditionally, false included, for the usual docker commit reason: a true stamped once would ride the snapshot image into every future container and make the switch impossible to turn back off. A missing label reads as false and off is byte-identical to today, so no existing project is churned. Requesting the device fails at creation when the host kernel has no tun module, which would otherwise surface as a project that simply refuses to start. explain_create_failure() rewrites that one error to name the switch and the Docker-Desktop-VM-versus-your-machine distinction, and leaves every other failure untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-14 08:06:39 -07:00
shadow-testandClaude Opus 5	84a67fcd0d	Stop an empty base-image label from silencing the migration notice ... A project can be out of date and say nothing about it, in two ways that compound: the lineage lookup treats "unknown" as an answer, and the fallback that exists for unknown lineage disappears when its probe fails. `create_container` always writes triple-c.base-image-id, even when the value is unknown — deliberately, so an inherited image label cannot ride a snapshot forever. That makes Some("") the ordinary reading from a container whose lineage was never established. The lookup filtered for emptiness only on the final result, so that empty string satisfied the container branch and skipped the snapshot entirely: a snapshot that had recorded a real lineage was never consulted, and the project reported "unknown" with the answer one lookup away. Each source is now filtered before it can answer, in pick_recorded_lineage, which is a plain function so the case has a test that fails against the old logic. A genuinely pre-label project stays unknown, and should: its ancestor is not knowable, and inventing one would make it look permanently current. The probe is the intended signal for those — but if the probe failed, get_container_staleness returned early with nothing populated, the banner found no gaps and rendered null, and the probe_error it already knew how to display sat behind a gate that returned before reaching it. Silence there is indistinguishable from "up to date", and it is likeliest for the oldest and largest projects, whose manifests are the ones apt to exceed the inspection limit — one real project measured 6.93 MB against an 8 MB cap. An unknown-lineage container whose probe failed now says the check could not be completed, with the reason, under the tone that means unresolved rather than the one that means something is wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 21:24:51 -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	9b2f4fe79f	Give the env var its value box back, and stop labelling the secret ... Two separate faults, both reachable from one screenshot of the Global Environment Variables editor. The value input was collapsed to a sliver, so a variable looked like it had lost its value. `inputClass` carries `w-full`, and the `w-2/5` on the key input did not beat it — class-attribute order is not what resolves that conflict, stylesheet order is. The key therefore asked for the whole row, and the value input, whose `flex-1` gives it a basis of 0 and only the leftover space, got almost nothing. Widths now live on wrapper divs, where nothing competes with them. The fingerprint that detects custom-env changes was a plaintext `KEY=VALUE` join, and it is written as the `triple-c.custom-env-fingerprint` label. Labels are readable by anything on the host via `docker inspect`, `docker commit` copies them onto the project's snapshot image, and the recreation check logs both sides on a mismatch — so an API token set as a custom variable was published to all three. It is hashed now, exactly as `triple-c.git-token-hash` already was. Empty stays empty, so "nothing configured" still reads as an empty label. Changing the fingerprint format means every project's label mismatches once: expect a single container recreation per project on next start. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 15:27:19 -07:00
shadow-test	d15faa923b	Give the app a mark that survives being 16 pixels tall ... The icon is now a container with its right wall opened, so the enclosure itself is the letter C, holding a >_ prompt: the two things the app is, in one closed shape. It carries no type, so nothing goes illegible when the shell draws it small, and it uses the app's own accent tokens rather than a saturated orange field that fights the chrome behind it. icon.ico contained a single 16x16 image, which Windows was upscaling into the taskbar and every other slot — the likely cause of the artefact in screenshot_for_fix/. It now carries 16, 24, 32, 48, 64, 128 and 256, each rendered from vector rather than downsampled from one bitmap, and the entries at 32 and below come from a separate optical source: at that size the cursor bar closes up against the chevron, so the small variant drops it, widens the mouth and thickens the strokes. A test asserts the .ico keeps its small sizes so this cannot regress silently. Also adds the icon.icns that macOS bundles have been building without, points the favicon at our own mark instead of the missing /vite.svg, and puts the SVG sources, the lockups and the regeneration script in branding/. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 12:01:39 -07:00
shadow-testandClaude Opus 5	ab747ce53d	Say what "open in container" is doing, and land on the pane doing it ... Opening a page is a container probe, a browser launch, a page load and often a viewer start — several seconds during which the only feedback was the click itself. Worse from a terminal, where the result appears in a pane the user is not looking at. So: the backend emits progress on the existing `container-progress` channel at each step, the Browser tab renders that line whenever it is set — the progress belongs to the project, not to whoever pressed the button, which is what lets a terminal-initiated open report anywhere at all — and the terminal's "In container" now selects the project's Browser tab before starting, so the line has somewhere to appear. Selecting a sub-tab from outside needed a route: `ProjectHome` keeps it in local state, so `openProjectHomeTab` parks a request in the store and the pane consumes it once. Consumed once, so it cannot fight the user's own clicking afterwards. Preview releases now prune themselves to the newest KEEP_PREVIEWS (2), in a job that runs only if all three platforms published — a half-finished run must not evict a good older build. The cleanup workflow's manual sweep stays as the backstop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 11:13:21 -07:00
shadow-testandClaude Opus 5	85ea3956e8	Stop the drag from selecting the tab's text ... A pointer-driven drag is still a mouse drag as far as the browser is concerned, so moving a tab highlighted its label blue — something the OS drag image never did, and the last visible difference between this and a real drag. `select-none` on the tab. The rename field gets `select-text` back: `user-select` inherits, and selecting text is exactly what that field is for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 11:00:06 -07:00
shadow-testandClaude Opus 5	f239fa1c82	Fix three things found by actually using it ... **The drag showed no tab.** Moving to pointer events lost the drag image the OS used to supply, leaving a dimmed source tab and a 2px line — which reads as "some setting changed", not "I am holding this tab". A copy of the tab now follows the cursor, carrying its glyph and its real label, grabbed at the offset it was picked up by so it sits where the tab was. **The URL relay opened a different URL than the one on screen.** Observed: `repo.anhonesthost.net/…/tag/preview-63f3c54` arrived as `repo.anhonsthost.nt/…/preview-63f3c54Butitprovesyournitpick…`. The detector deleted *every* line break to undo PTY hard-wrapping, but a terminal that wraps at a space emits the break **instead of** the space — so deleting breaks also deletes the separators, gluing the following paragraph onto the link and running the match past the host. Only breaks the terminal inserted may be deleted, and those are exactly the ones at the column width. The detector now takes a live column getter and rejoins a line only when it is exactly that wide; every other break becomes a space, which is also what stops a URL match. Lines *longer* than the width are left alone — the stream had no break there, so the one that follows is the application's own. One case stays ambiguous: a URL whose length is an exact multiple of the width is indistinguishable from one that was cut. That is pinned in a test as known behaviour rather than papered over — the candidate is shown in full and nothing opens without the user pressing Open. **"In container" opened a page nobody could see.** It bound the browser and stopped, leaving the user to find the Browser tab and press Start, with nothing saying so — and from a terminal, no pane on screen at all. Opening a page now starts the viewer if it isn't running, and the terminal's prompt raises the pop-out window, because that caller has nowhere else to put it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 10:36:30 -07:00
shadow-testandClaude Opus 5	f68d9c5788	Open a page in the container's browser, at a viewport you choose ... The pane could only ever watch a browser something else had published. This opens one: a URL and a viewport, launched inside the container and bound so the pane picks it up. Two uses, one action — a sign-in page, where the callback listener is *in* the container and the loop closes with no host round trip and no auth bridge, and a dev server on container loopback, which is how you watch a UI Claude is building. Reachable from both places the question comes up: "Open a page…" in the Browser tab, and an "In container" button on the terminal's URL prompt. Verified first, because it decided the design: a second client cannot join a bound browser. `chromium.connect()` against the published endpoint times out in every URL form (`ws+unix://…`, with and without the trailing path) — that socket speaks the dashboard's own transport, not the public connect protocol. Whoever launches is therefore the only process that can drive, so the helper is resident and holds the handle, and live resize applies to pages we opened and never to `@playwright/mcp`'s. Those take `--viewport-size` / `PLAYWRIGHT_MCP_VIEWPORT_SIZE` at launch, which the docs now say. The viewport is the interesting half. Resizing the *window* does nothing to the page — the viewer is a CDP screencast, so a bigger window is the same pixels drawn larger, which is why pages have been looking like they were rendered small. `page.setViewportSize()` genuinely reflows: measured against a `@media (max-width: 900px)` rule, it fires at 800×600 and clears at 1440×900. Match-window mode pushes the pop-out's settled size into it, debounced by generation counter because a drag emits `Resized` continuously and each one costs a container exec. Control is a polled JSON file in /tmp: no port, no second listener, nothing added to the proxy's surface, and URLs travel as argv to `node` so no shell ever parses one. A re-open with a helper already up navigates instead of relaunching — otherwise the second page would throw away the session the first one just signed into. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 09:15:12 -07:00
shadow-testandClaude Opus 5	bd72781482	Install one Playwright tree, and notice when a container has two ... Setup installed `playwright@latest` and `@playwright/cli@latest` together. Verified on a real container, that produces a tree that looks right and is broken: `@playwright/cli@0.1.18` pins `playwright-core@1.63.0-alpha`, npm hoists it, and `playwright@latest` (1.62.1) nests its own `playwright-core@1.62.1` beside it. The two cores want different browser revisions. The browser step runs the *resolved* — hoisted — CLI, so it downloads chromium-1237. Every script Claude writes says `require("playwright")`, gets the nested 1.62.1, and dies with: Executable doesn't exist at …/chromium_headless_shell-1234/… while the pane reports a browser installed, because one is. This is deterministic, not bad luck: every container set up through the pane lands in it. So the viewer package is installed first, and the `playwright` version installed after it is the one that package pins — read from the manifest npm just wrote, falling back to `@latest` only if it cannot be read. One core, one browser revision, both halves agreeing. Re-running "Set up Playwright" repairs an already-split tree. Detection now asks the question directly rather than listing a cache: it asks each resolved copy for `chromium.executablePath()` and whether that file exists — the viewer's copy *and* the one `require("playwright")` returns, since those are routinely different. `needs_browser()` covers "installed but not launchable", and the pane names both halves instead of saying "install a browser" over a cache that visibly has one. An absent field is "the probe didn't answer", never "skewed": containers predating these fields must not be told their browsers are wrong. The Rust side gets that from Option; the TypeScript mirror needed `!= null`, which an existing test caught. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 09:04:06 -07:00
shadow-testandClaude Opus 5	a41d93ea46	Fix the review's findings: drag on pointer events, read the window back ... Ten findings from the review of the previous commit, all applied. **The tab drag is now pointer events, not HTML5 drag-and-drop.** Two independent reasons, either one fatal. Tauri's `dragDropEnabled` blocks HTML5 drag inside the webview on Windows, and it cannot just be turned off — `TerminalView` needs Tauri's native drag-drop event, which is the only one that carries dropped *file paths*. And an HTML5 drag carries a `DataTransfer`: released over any text field in the app, the default handler types `term:<uuid>` into it, and in Config that is then saved with the project. Pointer events have neither problem, and the drag is measured from the tabs on screen rather than from the event target, so the marker and the drop agree even over the marker itself. Escape abandons a drag; a press under 4px stays a click; the click that ends a drag does not select. **`Ctrl+Shift+←/→` no longer swallows word-wise selection.** It is bound on `document` in the capture phase, so in any input — the rename field, Config, Settings — it was taking the OS's extend-selection chord *and* silently reordering the strip. Guarded by `inTextField()`, which excludes xterm's helper textarea: that is an input-method shim, and the terminal is where the shortcut matters most. **The pop-out's state is read from the window, never remembered.** The pane is unmounted whenever another Project Home sub-tab is selected, so "Keep on top" came back Off over a window still floating on top. `get_browser_view_popout_state` returns both facts from the window itself, and the change event carries them. `poppedOut` is tri-state: until the answer arrives the iframe is not mounted, because guessing "not popped out" is what flashes a second viewer onto the browser. Also: `popout::close` and the off-status emit in the supervisor are behind the same epoch guard as the deregistration above them, so a supervisor whose teardown outlives a restart can no longer destroy the *new* session's window; `close()` returns its `destroy()` error instead of logging it and reporting success, since the pane restores its iframe on success; the drop marker is `pointer-events-none` and is placed before the first *visible* tab at or past the slot, so it neither refuses a drop nor vanishes when a `tabOrder` entry renders nothing; and the "Keep on top" Toggle's accessible name now matches its visible text. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 07:40:51 -07:00
shadow-testandClaude Opus 5	d73096c937	Reorder tabs by dragging, and pop the browser view into its own window ... Two things the UI couldn't do: rearrange the tab strip, and watch the browser while working somewhere else. **Drag to reorder.** `moveTab`/`moveActiveTab` on the store, HTML5 drag on the strip with a marker showing where the drop lands, `Ctrl+Shift+←/→` for the same thing without a mouse. Reordering deliberately does not select what it moves, so a drag aimed at a background tab doesn't yank the main area away from a terminal mid-run. A tab being renamed is not draggable — a draggable ancestor swallows the mouse-drag that selects text in its input. **Pop the browser view out.** `browser_view/popout.rs` opens the view's existing token-bearing loopback URL as a second OS window, with a "Keep on top" toggle so it can float above the app. Window-only: the viewer, the proxy and the container are untouched, so popping out and back interrupts nothing. Three things it rests on: - No capability lists that window, so it has no IPC surface — right for a page served out of a container, and it must stay that way. - The app CSP is irrelevant to it: `frame-src` constrains what the app's document may *embed*, and this is a top-level document. The port range and the token gate are what actually protect it, unchanged. - The window is owned by the session, so the supervisor's teardown closes it. A window onto a viewer that no longer exists is worse than none. The pane drops its iframe while popped out — two viewers can both *drive* the browser, and two cursors on one page is not a feature. `lib.rs`'s `on_window_event` is now guarded on `label() == "main"`. It fires for every window and its body stops every container and exits, so without the guard closing a pop-out would quit the app. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 06:50:40 -07:00