5 Commits

Include renames

Author	SHA1	Message	Date
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	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
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	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	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