187 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5.5	60c03baf62	Marketplace: explain, don't offer, updates that would be refused (PR re-review) ... ItemUpdate gains invalid_at_head: compute_updates records why the item cannot be installed at head (catalog invalid, or gone) — the rule update_marketplace_item applies — read once per marketplace from the snapshot at head, else from the catalog parsed at head. The Installed row shows that reason instead of a Review button, and the update counts in the Marketplace tab and Settings count only applicable updates. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 13:22:01 -07:00
shadowdaoandClaude Opus 5.5	8ec033f923	Marketplace: match an update to the install pinned at its commit (PR review #8) ... InstalledPane's updateFor now requires u.pinned === i.commit, so an install of the same item at another (unchanged) commit no longer borrows another install's update and shows a phantom one with an empty diff. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 13:13:11 -07:00
shadowdaoandClaude Opus 5.5	fe15f541b9	Marketplace: toast a refused account change and refresh after a saved one (PR review #7) ... changeAccount now catches a rejected updateMarketplace (e.g. an account for another host) and toasts it instead of leaving an unhandled rejection, and refreshes the marketplace after a successful change so the old fetch error is replaced. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 13:13:11 -07:00
shadowdaoandClaude Opus 5.5	da65d51f09	Marketplace: review a plugin's catalog entry and confirm what it runs (PR review #3, #4) ... A plugin's update diff now includes its marketplace.json entry as a pretty-printed "marketplace.json entry" file, so inline hooks, MCP servers and commands are reviewed like any file. CatalogItem gains plugin_components (entry / plugin.json runnable keys, hooks/hooks.json, .mcp.json, commands/), and installing a plugin now goes through PluginConfirmModal listing them. The import-preview warnings describe that confirmation accurately. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 13:08:15 -07:00
shadowdaoandClaude Opus 5.5	dd019cf2c0	Marketplace: pin the commit the user reviewed (final review I2) ... Install and update pinned whatever the marketplace head was when the click landed, so a background refresh between review and click could pin content nobody saw (including a hook's shell commands). install_marketplace_item and update_marketplace_item now take expected_commit and refuse with "changed since you reviewed this item — review it again" unless it is still the head. The UI passes the head the selected item was read at (Browse), the head frozen with a pending hook confirm (whose commands are frozen too), and the head of the accepted diff (Installed). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 10:11:19 -07:00
shadowdaoandClaude Opus 5.5	2c1d6d8713	Docs: marketplace, and clean up new-code warnings/lints ... CLAUDE.md gets a Marketplace subsection under Key Conventions (the sync script is app-embedded and re-uploaded on every sync, never baked into container/ — pre-flight F9) and the Settings export/import section now covers marketplace account tokens traveling in ExportedSecrets and the import preview's warning on global hook and plugin installs. HOW-TO-USE.md gets a Marketplace section (placed after Shared Claude Authentication) with its Table of Contents entry (pre-flight N13). The spec doc's stale keychain service name, gh-login flags and upload_bytes_to_container signature are amended to match the shipped code (pre-flight N10). Also fixes the new marketplace code's remaining build/clippy warnings: BTreeMap/Sha256/Digest imports in tree.rs gated behind #[cfg(test)] (their only uses are on MemTree, already test-only), the unused `pub use marketplace::*` glob re-export dropped from models/mod.rs, gh_login::strip_ansi marked #[cfg(test)] (production streams through AnsiStripper instead), and four clippy lints in marketplace test code (double_ended_iterator_last, cloned_ref_to_slice_refs x2, single_match). Flushes the unresolved getMarketplaceSyncReport promise in MarketplaceSection.test.tsx's "opens the Marketplace filtered to this project" test to remove its act() warning. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 09:54:24 -07:00
shadowdaoandClaude Opus 5.5	9588687934	Merge Tasks 12–16 (marketplace frontend) into feat/marketplace ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 09:48:48 -07:00
shadowdaoandClaude Opus 5.5	6cf9664dc8	Marketplace: warn on imported global plugins; tidy import follow-ups ... - The import preview counts global plugin installs and warns on them: a plugin can bring hooks and MCP servers into every container and an imported install skips the confirm step, like a hook. - Item keys, hosts and branches in errors are quoted with {:?} and capped, since they can come from an import file. - After an import, caches and snapshots of marketplaces the import dropped are removed (under the repo lock) and pins are refreshed for the imported installs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 09:46:56 -07:00
shadowdaoandClaude Opus 5.5	f4153dce42	Marketplace: Tauri commands, store-owned fields and startup refresh ... The 21 marketplace commands, registered and granted; marketplace fields kept store-owned in update_settings/update_project; a background refresh of every marketplace at app start. - apply_marketplace_now emits marketplace-sync-finished per project (F4). - Settings export carries marketplace account tokens in ExportedSecrets (account id -> token) and import restores them; imported accounts, marketplaces and global installs are validated with the commands' own rules before anything is written. The import preview discloses the marketplace count, token count and global hook installs, and warns on the latter (F10). - refresh_pins and cache removal hold the repo lock (F11). - ops::validate_host/validate_branch delegate to auth::valid_host and git::valid_branch (F13). - A finished gh container login frees only its own cancel slot. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 09:41:59 -07:00
shadowdaoandClaude Opus 5.5	28c8f0479b	Project Config: Marketplace section with per-project opt-out and last sync report ... Shows items this project gets from "All projects" installs (with a per-item opt-out switch saved through setGlobalItemDisabled, since opting out doesn't require a stopped container) and this project's own installs. Fetches the last sync report on mount and refetches it when marketplace-sync-finished fires for this project (N7, preflight), so Apply Now and container-start syncs don't leave it stale. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 09:08:12 -07:00
shadowdaoandClaude Opus 5.5	f3909084f6	Marketplace UI: accounts — gh on host, gh in a container, access tokens ... Per preflight F5, Remove is disabled with a hint for an account a marketplace uses rather than offering a confirm modal that promises a removal the backend refuses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 09:03:38 -07:00
shadowdaoandClaude Opus 5.5	487443c27c	Marketplace UI: installed list, update diff review, apply now ... Applies preflight rulings F4, F7, F8, N5: Apply now's toast shows only the success/info summary (the marketplace-sync-finished event listener already toasts per-project errors/skips, so this avoids a double toast); row removal passes the bare MarketplaceItemRef rather than the full MarketplaceInstall; UpdateDiffModal shows a hook's rendered commands at head above the file diff so an update is reviewed the same way an install is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 08:58:38 -07:00
shadowdaoandClaude Opus 5.5	3c12a2fc89	Marketplace UI: browse, item detail, install controls, hook confirmation, add marketplace ... Implements Task 13: BrowsePane (marketplace list, kind/search filters, item detail), InstallControls (global/per-project install, opt-out, hook confirm gate), HookConfirmModal, AddMarketplaceModal, and ItemDetail. Also applies pre-flight ruling F6: a per-marketplace Remove button with a confirm dialog (mp.remove) warning that surviving installs become "Source removed" and can be dropped via Forget on the Installed tab, plus an inline account reassignment select (updateMarketplace + reloadState). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 08:54:02 -07:00
shadowdaoandClaude Opus 5.5	d23d0a44c5	Marketplace UI plumbing: wrappers, singleton tab, settings section, view shell ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 08:48:06 -07:00
shadowdaoandClaude Opus 5.5	d419d0a6b4	Marketplace: data model, settings and project fields ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 08:40:58 -07:00
shadowdaoandClaude Opus 5.5	ece0d74afb	Settings: let the shared-auth buttons wrap inside the sidebar ... Re-authenticate, Revoke and Check snapshot images are each nowrap and together wider than the settings sidebar, so the last one ran outside its container. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 06:41:43 -07:00
jknappandClaude Opus 5.5	0d117e97fe	Add Auto permission mode (#63) ... Adds Claude Code's auto permission mode as a fifth option between Accept Edits and Bypass, across terminals, resumed sessions, the tab badge, the scheduler task runner and docs. Warns that Auto falls back to prompting when unavailable for the model/backend. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-25 17:02:06 +00:00
jknappandClaude Opus 5.5	8305c96e20	Terminal file viewer/editor + per-window app-command lockdown (#60) ... Clicking a file path in Claude's terminal output now opens the file in its own window with a CodeMirror 6 editor. The editor highlights the target line, live-reloads while the file changes, and saves explicitly with hash-based conflict detection. The viewer commands are gated by window label. Every app command is now ACL-gated per window through a Tauri AppManifest. build.rs checks the handler list against the capability files and fails the build on any mismatch. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-23 17:05:50 +00:00
shadowdaoandClaude Opus 5	83c9c24951	test: give two synthesised clicks the detail a real click carries ... The previous commit tightened the gate's click-count check from `> 1` to `!== 1`, which two tests in the wiring block did not survive: they built `new MouseEvent("click", { button: 0 })` directly rather than through the `click()` helper, so `detail` defaulted to 0 and the gate refused them. The gate is right and the tests were wrong -- a mouseup derived from a real click always carries `detail >= 1`, and 0 is exactly the synthetic-event shape the tightening was for. Both now pass `detail: 1`. I pushed the previous commit without noticing this, having read a truncated test summary that hid the failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 20:08:36 -07:00
shadowdaoandClaude Opus 5	c6f9c1d43f	fix: tighten the click-count check and stop three comments overstating ... Third-round review polish; no behaviour change beyond the first item. `detail > 1` was justified in a comment by noting a synthesised event carries `detail` 0 -- which is an argument for letting untrusted synthetic events through the click-count half of the gate. A mouseup derived from a real click always carries `detail >= 1`, so the check is now `!== 1`. Nothing in the container can dispatch a DOM event, so this is hardening rather than a hole; the comment now says that instead of the reverse. Three comments claimed more than they hold. The selection check's paragraph read as though it caught every copy gesture: it sees a drag only once the drag has spanned a cell, so a press and release inside one character cell -- or a drag walked back to its start -- still opens the link. That is the gap the rejected mousedown/mouseup distance check would have closed, and it is now recorded beside the reason for rejecting it. `?1002l` was described as taking effect synchronously with the write; it takes effect when xterm parses it, on its queued write task. And `modifierPromised` was described as written on every hover, when `hover()` clears and returns early with no host element -- which leaves it false, the stricter direction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 20:07:59 -07:00
shadowdaoandClaude Opus 5	593b8168eb	fix: a selection is not a request to leave the app ... Re-review found the gate did not cover the gesture users actually make. xterm's `Linkifier._handleMouseUp` has no click-count check, no distance threshold and no timestamp, so it activates on the mouseup that *ends a selection* as readily as on a click. Double-clicking a word or dragging across a few characters inside an OSC 8 link therefore opened the browser. Worse with a program holding the mouse: the only way to select text there is Shift/Option+drag, which is byte-identical to the gesture the gate accepted as a deliberate request to open. A container wrapping each output row in a link would have harvested every legitimate copy. `term.hasSelection()` is the load-bearing check: a drag is one press and one release, so its click count is 1 and `detail` cannot see it. `detail > 1` is belt-and-braces for the case where the selection came out empty, and for not depending on the selection model being written before the Linkifier's listener runs -- it is, but the check costs nothing. Drag distance was rejected rather than forgotten: xterm hands `activate` only the mouseup, so measuring it means binding our own listener and keeping a second source of truth about one gesture. The hover card's promise is now sticky. The hint was computed once at hover while the gate re-read the mode at mouseup, so a card reading "Shift+click to open" could be on screen while a bare click opened the link. The gate now requires the modifier if either the card asked for it or the live mode does. The same gate is applied to the WebLinksAddon branch, which had none. That also closes a real bypass: `OscLinkProvider` drops non-http(s) OSC 8 targets before `linkHandler` sees them, so a `javascript:` target with an `https://evil.tld` label fell through to WebLinks and opened ungated. What is not closed, and is now recorded rather than papered over: the mouse mode is a permission the container grants itself. It can drop tracking before the pointer arrives and hold it off through the click. The selection and click-count checks hold either way, so the mass-harvest variant is gone, but the real fix needs a signal the container cannot write and this pane does not have one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 20:00:42 -07:00
shadowdaoandClaude Opus 5	ac50c38891	fix: gate OSC 8 link activation instead of merely hinting at it ... Review of this branch found its central premise was false. The claim was that xterm cancels a mousedown before the link layer while a program holds the mouse, so only a Shift+click could reach a link. None of that holds: `cancel()` is `if (this.options.cancelEvents || force)` and `cancelEvents` defaults to false and is never set here, so it does nothing; the mouse reporting listeners bind to `.xterm` while the Linkifier is constructed on `screenElement`, a descendant, so the link layer sees the event first regardless; and `_handleMouseUp` checks neither the modifier nor the button before calling `activate`. So a plain click opened the link, and so did a right-click. That is not a missing convenience. OSC 8 lets the container wrap any clickable TUI widget -- a menu row, a "1. Yes", a file chip -- in a link to anywhere, and because the mouse report still reaches the program afterwards the widget responds too and nothing looks wrong. The hover card was the only mitigation, and it assumes a user deliberately reaching for a link. `opensOnClick` is now a real gate: primary button only, and while a program tracks the mouse the force-selection modifier is required -- the gesture the user already has for "this click is for the terminal, not the program". With nothing tracking, a bare click opens, which is what WebLinksAddon already does for plain-text URLs in the same buffer. The mode is read per click through a getter rather than captured, and `syncMouseCapture` and the gate share one expression, because a gate that disagreed with the badge would be the hole again. The gate and the hint also share one modifier predicate, and the hint is conditional on tracking, so it can never name a key that does nothing. Three more from the same review. The origin span had `flexShrink: 0`, which beats `overflowWrap` under flexbox, so an attacker-controlled 600-character origin ran off the pane and hid the registrable domain -- the same spoof as an ellipsis, without one; it now wraps and the remainder is what gives way. The card had no `pointerEvents: none`, and `xterm-hover` is inert at this placement, so a card under the pointer took `mouseleave` from screenElement and made bottom-row links flicker and refuse to activate at all. And the design doc comment had come adrift from its function. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 19:45:11 -07:00
shadowdaoandClaude Opus 5	f311ca1990	feat: make links in Claude's output clickable ... Claude Code prints links as OSC 8 hyperlinks whose visible text is hard-wrapped into terminal-width pieces -- urlDetector's header records a 346-character sign-in URL arriving as five emissions, each carrying the whole URL in its parameter and about 80 characters on screen. WebLinksAddon regex-matches the painted characters row by row, so against Claude it matches a fragment or nothing, which is why the URL toast exists. xterm 5.5 hands over the exact parameter through `linkHandler`, so the slicing stops mattering. WebLinksAddon stays for plain-text URLs in ordinary shell output; the two cover different cases and neither replaces the other. Both now share one failure reporter and one validator. No new key handling was needed. xterm's mousedown handler is `if (areMouseEventsActive && !shouldForceSelection(e)) return cancel(e)`, so holding the force-selection modifier lets the event reach the link layer while Claude still holds the mouse -- Shift+click, or Option+click on macOS, which this terminal already enables for text selection. The hover card is the security half rather than decoration. OSC 8 decouples the label from the target completely: a container can print `https://claude.ai` and link it anywhere, which is strictly worse than the userinfo spoofing already guarded against and which invalidated the justification for opening a click without confirmation ("a deliberate act on visible text"). Hovering now shows the real origin, in full and never truncated, because truncating it is the spoof. A target that fails validation says so and deliberately echoes nothing of itself. The hint names the modifier for the platform, from xterm's own `isMac` list, so it cannot tell a Mac user to press a key that does nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 19:23:18 -07:00
shadowdaoandClaude Opus 5	60188610ee	fix: do not let an in-flight open blank a newer prompt, or promise a bridge that is off ... Two findings from review of this branch. Awaiting the open instead of dismissing up front bought a window: on Linux it is at least OPENER_GRACE, doubled when xdg-open fails and gio is tried. If the container relays a second URL inside that window, the first open's resolution blanked the second prompt -- losing a link that exists only in the container's transcript, which is the failure "dismiss on success only" was made to prevent. The slot already carried a `seq` for exactly this reason; dismissal is now conditional on it. `urlPromptRef` is written eagerly by the two functions that change the slot rather than synced by an effect. That is load-bearing: an effect-synced mirror lags state by a commit, and a promise microtask can resolve between `setUrlPrompt` and React flushing passive effects -- so it answers "did a newer prompt land?" wrong in precisely the window the guard exists for. Dropping the functional updater also fixes `promptSeqRef.current += 1` being mutated inside a state updater React is free to invoke twice. The guard is a sibling function rather than an optional argument on `dismissUrlPrompt`, because that function is passed by reference as UrlToast's `onDismiss` and React would hand it a MouseEvent as its first argument -- the seq check would fail and the close button would silently stop working, with the types still assignable. Separately, the sign-in hint was binary on which button leads, but "host leads" covers both a live bridge and a fallback where nothing is set up to catch the callback at all. In the second case the toast promised the bridge would carry it and the login hung to its timeout. The target is now three-state, the hint tells the truth in the fallback case and names the control that fixes it, and the hook starts at `host-fallback` rather than assuming a bridge it has not confirmed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 11:12:22 -07:00
shadowdaoandClaude Opus 5	5a09254538	fix: route every host-browser open through open_url_external ... The Rust command existed but nothing called it. All four frontend call sites still used `openUrl` from `@tauri-apps/plugin-opener`, so the environment fix was inert and the three dialogs carried the same Linux bug as the terminal: DockerInstallDialog's docs link, ClaudeAuthModal's sign-in link and UpdateDialog's release link would all have reported success while launching nothing. `openUrlExternal` in tauri-commands.ts is now the single sink. There is no platform branch: Linux gets the sanitized spawn, macOS and Windows reach the same plugin as before but from Rust, and every platform picks up the Rust-side re-validation, which matters because these URLs originate in an untrusted container. Comments in urlRelay.ts and urlDetector.ts that named `openUrl` as the sink they guard are updated to match, and the two test files that mocked `@tauri-apps/plugin-opener` now mock the command instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:09:57 -07:00
shadowdaoandClaude Opus 5	bf8094dbc4	fix: route sign-in links by what can actually catch the callback ... `isAnthropicSignInUrl` made the container the default action for every Anthropic sign-in link, justified by "the host has nothing to catch it with". That was wrong in both directions. The host does have something -- the auth bridge -- and the container side is not a general browser at all but Playwright's dashboard, whose packages and chromium are deliberately not baked into the image. So the default pointed at the one path that is uninstalled on a fresh project, on every platform, while the path that works sat behind a switch. The decision now lives in `useSignInOpenTarget`: a live auth bridge picks the host, otherwise a container that can actually launch a browser picks the container, otherwise the host. It resolves at mount rather than when a URL arrives, so the buttons do not swap under a moving mouse, and it re-decides on `auth-bridge-changed` so flipping the switch during a hanging login takes effect. A bridge with port conflicts reads as not live; an empty `active_ports` does not, since there is nothing to bridge until the CLI binds its listener and that races the URL. Both buttons still render either way -- this changes which one leads. `sanitizeRelayUrl` is byte-for-byte unchanged, so the embedded copy in web_terminal/terminal.html needs no matching edit. The host "Open" path also failed silently: `dismissUrlPrompt()` ran before `openUrl`, so the toast vanished and a rejected promise reached only the devtools console. Dismissal now happens on success only, leaving "In container" one click away after a failure, and the error surfaces through the same toast the container path already used. On Linux this catch will not fire for the common case -- `xdg-open` routinely exits 0 having done nothing -- so it complements the AppImage environment fix rather than replacing it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:07:50 -07:00
shadowdaoandClaude Opus 5	c0e4c87cec	Give the mouse back, retire the follow controls, update Claude per session ... Three things the terminal was getting wrong. **A program that grabs the mouse and dies used to freeze the tab.** A TUI sets DECSET ?1000/?1002/?1003; if it exits without resetting them, xterm keeps routing clicks, drags and — under ?1003 — every pointer *move* to the PTY. Text selection dies and escape bytes flood the prompt. The only exit was closing the tab. `TerminalView` now reconciles a flag against `term.modes.mouseTrackingMode` in the `term.write()` callback — the mode only changes because the container printed a sequence, so one check per write catches every transition with no polling — and `Ctrl+Shift+X` or a status-bar button writes the resets back through `term.write`, never `sendInput`: the reset belongs to xterm's parser, and a still-live TUI told about it would just re-grab on its next repaint. The control is in the status bar deliberately. Mouse tracking is the *normal* state of htop, vim, lazygit and Claude Code, so a badge over the terminal would be on screen for the whole life of those programs and would swallow clicks aimed at their own top-right corner. `macOptionClickForcesSelection` is also on now: xterm's force-select is Shift everywhere except macOS, where it is Option and is gated behind that option, which defaults to false — so until now Mac users had no way to select text while a program held the mouse. **"Following" and "Jump to Current" are gone.** Claude Code draws on the alternate screen, which has no scrollback, so `viewportY` always equalled `baseY` and neither control could do anything. They did still work in bash tabs; xterm's native follow covers that, and the per-write `scrollToBottom()` went with them because it fought exactly that. What remains, on activate and after a refit, now samples `viewportY >= baseY` *before* the fit, so opening the Notes dock no longer yanks a reader to the tail. **`claude update` runs before every Claude session, not just at container start.** Containers here stop/start and often just keep running, so a long-lived one never re-checked. Both copies take the same flock: the entrypoint prints "container ready" only after its own update finishes, so opening a tab immediately would otherwise run two updaters against the same ~/.claude/bin, with `|| echo` hiding a half-written install one line before `exec claude` ran it. This turns the non-Bedrock path from a bare argv into a `bash -c` wrapper, so flags and session names are shell-interpolated now and must go through `shell_quote_arg`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0145mQi9NZiCDrznBUEEDE4n	2026-09-08 11:02:33 -07:00
shadowdaoandClaude Opus 5	c16f0d5b70	Put the cursor in the terminal after sending a note ... Sending already switched to the target terminal's tab, which looks like it should be enough: `TerminalView` focuses xterm whenever a terminal becomes active. But that effect keys off `active`, so it only fires on a *change* — and the dock's ordinary case is sending to the terminal already on screen. `setActiveTabKey` writes the key that is already set, nothing changes, no effect re-runs, and focus stays on the Send button. The note is sitting in the prompt and the user still has to click the terminal before pressing Enter. So the send now asks for focus explicitly, through a one-shot request in the store that `TerminalView` consumes and clears — the shape `pendingHomeTab` already uses. Clearing is not tidiness: hold the id and the second send to the same terminal writes a value that is already there, which is precisely the no-op this exists to fix. Focus is requested only on success. A failed send toasts and leaves the user where they are, because there is nothing in the prompt to press Enter on. The three `TerminalView` tests give focus away after mounting before making any assertion, so what they observe is the request landing and never the focus that `active` already grants on mount — which would pass with the feature absent. 752 tests pass, 62 files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 13:28:31 -07:00
shadowdaoandClaude Opus 5	3239057f8f	Give the dock its own compact notes layout ... The dock was showing `NotesPanel`, which is a master/detail layout: a column of titles beside an editor. The previous commit made that survive dock width; it did not make it right. At 352px the layout still spends roughly 356px of height on chrome — dock header, panel header, title strip, a button row that wraps, and a paragraph of help — before the body gets a pixel. So the dock now shows one note. The title field names what is open and the chevron beside it switches; New and Delete move into the overflow menu; the help text goes. Chrome drops to about 112px and the body takes the rest. The two surfaces are now different components, which contradicts a docstring I wrote — "shared so the two cannot drift into different behaviour". That claim was about behaviour, and behaviour was never in the layout: it is in `useNotes` for the cache and its write ordering, and now in `useNoteDraft`, extracted here so when a keystroke becomes a save is defined in exactly one place. Only the layout diverges. `NotesPanel.shared.test.tsx` gets stronger for it — it now mounts the dock panel and the tab panel together, which is what the app actually does, instead of the same component twice. `NoteSwitcher` is not `OverflowMenu` despite the shape being close: that keys items by label, and notes are addressed by id, so two untitled notes — the ordinary case — would collapse into one row. It is also not a `combobox`; an input plus a listbox button is two honest controls, where the role would owe active-descendant tracking and filtering that nothing here needs. `SendToAgentButton` picks up `useUnavailable` from #49, which is what its `disabled` plus explanatory `title` was already asking for. Four tests moved from `toBeDisabled()` to the new contract, and one of them — "does nothing for an empty note" — turned out never to have asserted that it does nothing. It does now, for click and for Enter, which is the guard the swap needs. It also gains `dropUp`, and that is load-bearing rather than cosmetic: the dock clips its own overflow, so a session menu opening downward from a button on the bottom edge is drawn outside the panel and never seen. 744 tests pass, 62 files. As before, jsdom has no layout engine: that the dock now reads as compact is not something the suite can tell you. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 12:10:00 -07:00
shadowdao	23364f412e	Merge remote-tracking branch 'origin/main' into feat/project-notes	2026-09-02 12:04:17 -07:00
shadowdaoandClaude Opus 5	0f3fff92f4	Lay the notes panel out by its own width, not the window's ... The panel splits master/detail unconditionally: a 192px title column beside the editor. That fits the Project Home tab and does not fit the dock. At the dock's 352px default the editor gets 157px, and its action row wants ~200px, so the Delete button lands outside the dock's `overflow-hidden` with no scrollbar to reach it, and the textarea collapses to a two-word column. The two surfaces differ in width while sharing a viewport, so this is a container query rather than a `md:` breakpoint — a viewport query reads the window and hands both surfaces the same answer, which is wrong for one of them. Tailwind v4 has these in core; verified as real `@container (min-width: 32rem)` rules in the built CSS, since a variant that silently compiles to nothing looks identical in review. The threshold is arithmetic: side by side needs the 192px list, an editor wide enough for its own buttons (~280px), and the divider. `@lg` (512px) is the first stop clearing ~473px. Below it the titles become a capped strip above the editor, so the note being written keeps the height. The action row now wraps, which is the part that holds at *any* width rather than on one side of a threshold: the buttons are a group that does not shrink, the title field shrinks to 96px, and past that the title takes one row and the buttons the next. Nothing can be pushed out of the panel. Not covered by the suite — jsdom has no layout engine, so 711 tests pass before and after. This needs eyes on the dock at its minimum, default and maximum widths. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 11:34:02 -07:00
shadowdaoandClaude Opus 5	1eb91a35eb	Give the terminal and Add Project buttons a reason a screen reader can hear ... Both were the defect the new hook exists for. The sidebar's Claude terminal button is disabled whenever the container is not running and never said so — its `title` names the action, so the precondition appeared nowhere in the accessibility tree at all. Add Project's submit button is disabled while an add is in flight, and its only signal is the label swapping to "Adding…" on an element a screen reader can no longer reach. The submit button needs a second guard the hook cannot supply: Enter inside a text field submits a form without touching the submit button, so `handleSubmit` now returns early while loading. Without it, swapping `disabled` for `aria-disabled` would have turned an accessibility fix into a double-submit bug. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 09:08:57 -07:00
shadowdaoandClaude Opus 5	aa0a574091	Announce unavailable controls instead of hiding them behind disabled ... Native `disabled` removes an element from the tab order and from the accessibility tree, so any explanation of why a control cannot be used is delivered only to a sighted user with a mouse. `useUnavailable` is the way out: `aria-disabled` keeps the control focusable and announced, `aria-describedby` carries the reason, and — because `aria-disabled` is advisory and blocks nothing — the hook hands back the click and Enter/Space guards along with the attributes, so a call site cannot take the announcement without the guard. `Button` gets it as an opt-in `unavailable` / `unavailableReason` pair. Opt-in matters: 37 files render this button and none of them change. The `aria-disabled:` class mirrors exist because Tailwind's `disabled:` variant only matches the native attribute, which this pattern deliberately omits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 09:08:50 -07:00
shadowdaoandClaude Opus 5	436b6dd470	Send a lone CR through the newline transform, and say what pinned is ... `toClaudePayload` matched `/\r?\n/`, so a bare CR that is not part of a CRLF went through verbatim — and a bare CR *submits* in a Claude prompt and *runs* the line in a shell, which is the terminator the function's own contract says it never appends. A `<textarea>` cannot produce one, but `load_in` returns whatever a hand-edited or externally written notes file holds, so the guarantee has to cover that rather than only what the editor can type. `Note.pinned` is persisted and sorted on, but nothing in the app sets it: there is no pin control and no indicator. The spec stated the ordering rule as though pinning existed and §8 did not list it, so the spec is amended to say `pinned` is reserved and inert in v1, and pinning is added to the out-of-scope list. No UI is added — a user-facing affordance does not belong in a fix wave. Also renamed NotesPanel.test.tsx's "deletes the selected note and falls back to another": `useNotes` is mocked in that file and the mocked list never changes, so the fallback was never exercised. A name that claims coverage which is absent is worse than an absent test, because it makes the gap invisible. The real assertion now lives against the real hook in NotesPanel.shared.test.tsx. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HjL1E2JFNctUqCYotUwqqb	2026-09-01 13:47:01 -07:00
shadowdaoandClaude Opus 5	5c47656444	Cache notes in one place, and serialise a project's writes ... Implements the design spec's §2 — "notes cached in zustand keyed by project id" — which the plan substituted with a hook-local `useState`. Sharing the `NotesPanel` *component* between the Project Home sub-tab and the dock did not share the *cache*. Both resolve to the same project, so two panels mount two `useNotes(P)`, each with its own list. Edit a note in the dock and blur; the tab's copy is still pre-edit, and the tab's next blur commits `{...staleRecord, title, body}` — the dock's edit gone from disk with no error and no indicator. That is the feature's own primary workflow: take notes in the dock while the agent runs, which is the reason the dock exists, then go back to the tab. `notesByProject` plus a per-project in-flight flag now hold the list. Both surfaces render from one array; two panels mounting for one project make one read; and because the write is keyed by project, a response that lands after the user has moved on updates the project it belongs to rather than whichever is on screen. This is also the boundary §8 says a detached notes window needs. Three more bugs in the same code, fixed with it: - Delete-after-edit could resurrect the note. Clicking Delete with the textarea focused fires blur first, so `save_note` and `delete_note` go out back to back; Rust's `write_lock` stops them interleaving but does not order them, and a delete that wins the lock is undone by the upsert behind it. A project's mutations now go through one promise chain, module-scoped for the reason `useTerminal`'s input queue is. - An unsaved draft vanished when any other note was saved, because the re-read replaced the list with the backend's. "New note" now persists, so the backend owns the row from the start — chosen over merging local drafts because a local-only row in a *shared* cache would exist in the panel that made it and nowhere else. - The save outcome was reported for the wrong project after a switch: the guard covered only the list replacement, so the new project's SaveIndicator flashed "Saved ✓" for the old project's write. The indicator now resets on a project change and reports only its own. `NotesPanel` also re-seeds its draft when the *stored* text of the note it has selected changes, so an edit made in the other surface reaches the editor and not only the list. It never overwrites something half-typed; that still blurs into a last-writer-wins save, as any blur-commit editor does. NotesPanel.shared.test.tsx is the configuration none of the existing tests had: two panels, one project, the real hook. Four of its six assertions fail against the previous implementation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HjL1E2JFNctUqCYotUwqqb	2026-09-01 13:47:01 -07:00
shadowdao	037ed78570	Test the dock's load-path clamp and keyboard resize direction ... - notesDockWidth store initialization now clamps/defaults a bad localStorage value on load, not just on write (verified this fails without the clamp). - The keyboard resize test asserts the exact widened/narrowed value instead of just that the setter was called, so a swapped or inverted arrow-key branch would be caught.	2026-09-01 13:22:35 -07:00
shadowdao	31e8f9df5f	Add the notes dock	2026-09-01 13:15:13 -07:00
shadowdao	3704064006	Add the Notes tab	2026-09-01 13:08:17 -07:00
shadowdao	f79a44e0a8	Add the send-to-agent button	2026-09-01 13:02:22 -07:00
shadowdao	5a8e24ccbe	Extract the Claude newline sequence and the session display name	2026-09-01 12:57:29 -07:00
shadowdaoandClaude Opus 5	3a49a67c1f	Fix terminal input reordering and Linux terminal rendering ... Two separate defects behind the same report: typing in a container terminal is sluggish on Linux, and a backspace can land *after* the characters typed behind it. The web terminal was the control that separated them. It shares the Docker exec, the PTY, `exec_manager`, the input channel and its serial writer task, and xterm.js itself — and it does not exhibit either symptom. Only three things differ, and each accounts for part of the report. **Input ordering.** Every keystroke was its own `invoke("terminal_input")`. That command is `async`, so Tauri spawns each one as an independent task, and those tasks then race for the session mutex in `ExecSessionManager::send_input` — nothing preserved the order the bytes were typed in. The serial writer downstream cannot help, because the order is already lost before anything reaches the channel. The web terminal gets ordering for free by awaiting `send_input` inline in a single WebSocket reader loop. `useTerminal` now holds a per-session queue: one write in flight at a time, the next only after the previous resolves. Anything typed meanwhile coalesces into the next chunk, which also collapses a burst of typing into a couple of IPC round trips rather than one per key. The queue is module scope, not hook scope, because `useTerminal()` is called from several components — a per-hook queue would leave speech-to-text, image paste and typing racing each other. Each caller's promise still settles only when its own bytes have gone, so `await sendInput(...)` keeps its meaning. **The DMA-BUF escape hatch did not exist.** `apply_webkit_wayland_workaround` left any pre-set value alone, including `0`, on a stated assumption that WebKitGTK reads the variable as a boolean. It reads presence, so `WEBKIT_DISABLE_DMABUF_RENDERER=0` disabled DMA-BUF exactly like `=1`, and no value a user could set got the accelerated path back. `0`/`false`/`no`/empty now remove the variable, which is the only thing WebKitGTK reads as enabled. The default is unchanged: unset still means disabled on Linux. **WebGL does not degrade to canvas here.** The comment on that workaround assumed `@xterm/addon-webgl` would fall back to the canvas renderer once DMA-BUF was off. Its constructor throws only when WebGL is *absent*, and with DMA-BUF disabled WebGL is still present — served by software rasterisation. So the addon loads and every frame is rendered on the CPU, slower than the canvas renderer it was assumed to fall back to. `AppSettings::terminal_gpu_ rendering` decides whether it loads at all: `None` is auto (on for macOS and Windows, off on Linux), `Some(_)` forces it either way from Settings → Terminal. `Option<bool>` rather than `bool` so the zero value means "we choose" instead of pinning every existing settings file to one answer. Verified: 643 frontend tests and 530 Rust tests pass, clippy clean, secret scan clean. The Linux rendering half needs confirming on a real desktop — neither symptom reproduces in a headless container. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ApLYH6ybHwQFkMCtKuHrrV	2026-08-28 12:51:18 -07:00
shadow-test	97e58db3c1	Close gateway-secret desync, TOCTOU, and undisclosed custom-image gaps ... Round 4 review findings: - Disclose and warn on a custom Docker image the import would set (HIGH): it's the image every project container is created from, so an undisclosed change here was a sharper version of the redirected-base-URL problem round 3 already flagged for the model backends. - Recreate a running gateway container when an import restores a new secret with the shape unchanged (MEDIUM): reconcile_gateway's shape comparison can't see a secret-only change, so the container would otherwise keep serving old key material indefinitely. - Report keychain write failures back to the caller instead of only logging them (MEDIUM): apply_settings_import now returns SettingsImportOutcome with secret_restore_warnings so a partial restore can't read as unqualified success. - Pin a hash of the previewed file's ciphertext and refuse to apply if it changed on disk (MEDIUM): closes a TOCTOU between preview and apply. - Sanitize and cap every free-form string a preview surfaces, and move the warning boxes above the replace list in the UI (MEDIUM): an unbounded base URL or image name could otherwise push the security warnings below the scroll fold. - Validate the Docker socket path on import the same as the SSH key and CA cert paths (LOW): it was the one mounted host path validate_settings_update didn't cover. - Fix ExportedSecrets::is_empty() to treat whitespace-only as blank, like every other secret-presence check in this feature (LOW). - Authenticate the file header as AEAD associated data (LOW, defense in depth) and correct two doc comments that overstated the password not being cached.	2026-08-27 14:24:06 -07:00
shadow-test	a606e3ab20	Validate settings imports before writing secrets; disclose base URLs ... A rejected import (bad env var name, disallowed host path) used to leave keychain secrets already overwritten while the settings themselves stayed unchanged. apply_settings_import now runs update_settings's validation (extracted into validate_settings_update) before any secret write. Also from this review round: sharpened two format-version tests that previously passed against the pre-fix code too, added a direct test for split_settings_and_secrets, warned on a dormant web terminal token even when the terminal import leaves it off, matched the password-length check to the frontend's unit of measure, zeroized the export plaintext buffer, and surfaced non-blank Ollama/llama.cpp/OpenAI-compatible/gateway base URLs in the import preview so a traffic redirect isn't silent.	2026-08-27 13:13:48 -07:00
shadow-testandClaude Sonnet 5	925e51e435	Fix a real credential-leak vector a review found, plus four smaller issues ... The headline finding: WebTerminalSettings::access_token is a live bearer credential for a server that binds every interface, stored as a plain field on AppSettings — which this feature was exporting and importing wholesale as if it were as inert as a port number. A crafted export file could set web_terminal.enabled and access_token together, and importing it (with no more warning than any other setting change) would silently stand up a LAN-listening terminal server with an attacker-known token on the victim's next launch. Fixed by carving the token out into ExportedSecrets, same as the other three global secrets, with the same "only overwrite what the import actually has" treatment — except that has to be done by hand here, since this one lives inside the AppSettings blob that gets replaced wholesale rather than in the keychain. Added SettingsImportPreview:: enables_web_terminal so "this turns on a listening service" gets its own visible warning in the confirmation modal rather than hiding inside a generic "settings replaced" bullet list. Also fixed: - read_and_decrypt checked format_version only after attempting to parse the full payload, so a future version bump that isn't deserialize-compatible would fail on the shape mismatch before the version check ever ran — and serde's type-mismatch errors quote the offending value inline, which is a real leak path since the plaintext here can hold a live credential. Now probes just the version field first, and neither error path interpolates the underlying serde message into what the user sees. - apply_settings_import cleared the pending-import path before it could fail, so a rejected import (an invalid host path, anything update_settings validates) dead-ended the modal with no way back except cancelling and reopening the file picker. The path is now only cleared on success. - Secrets are restored before the settings replace runs, not after — replacing settings is what triggers reconcile_gateway, and restoring secrets afterward left a real window where a gateway recreation happened against the destination's stale keys. - The 8-character password minimum was frontend-only; export_settings now enforces it too, since that's the actual boundary a weak password has to cross. The derived key and decrypted plaintext are wrapped in zeroize::Zeroizing (already in the tree via aes-gcm). Added test coverage the review named as missing: format-version ordering, the generic-error-message guarantee, non_blank's blank-vs- absent handling, and the new web-terminal preview/warning behavior on both sides of the IPC boundary. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 12:16:43 -07:00
shadow-testandClaude Sonnet 5	722d9aeff1	Add password-encrypted settings export/import ... Closes #35. Exports the host environment — global AppSettings (already the non-secret shape persisted to settings.json) plus the global secrets that live in the OS keychain instead (the shared Claude Code OAuth login, the model gateway's provider API key and master key) — to one password-encrypted file, and restores it on another machine. Per-project settings, per-project secrets, and Docker volumes are deliberately out of scope; this is not a project backup. Designed with the user in issue #35's comments: global settings only, no docker volumes, the password is the lock/key, and the export is portable as one file. Crypto (storage/settings_crypto.rs): Argon2id derives a 256-bit key from the password (memory-hard, meaningfully resistant to GPU/ASIC brute-forcing in a way PBKDF2 at any reasonable iteration count is not), AES-256-GCM does the actual encryption. A wrong password fails GCM's authentication tag rather than producing silent garbage. Salt and nonce are random per export and stored in the clear in the file header — their job is uniqueness, not secrecy. The save/open dialogs are opened from Rust, matching the boundary file_commands.rs's pick_save_path/pick_files_to_upload already establish: a frontend-driven dialog handing Rust a host path is the exact shape of bug that produced this app's past criticals. preview_settings_import resolves the chosen import path itself and remembers it (AppState::pending_settings_import) so apply_settings_import re-reads the same file without a path crossing back over IPC. The password is re-entered rather than cached between preview and apply, so nothing here holds decrypted plaintext in memory for longer than one command's execution; the preview returned to the frontend carries counts and presence flags only, never a secret value. Import replaces settings wholesale (an import is "restore this environment"), but only writes secrets actually present in the file — an absent secret means "the source machine never had this configured," not "delete this on import." Added storage::secure::store_gateway_master_key and get_gateway_master_key (read-only, unlike get_or_create_gateway_master_key which mints one as a side effect) since neither existed and import needs to restore an exact captured value rather than mint a new random one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 11:57:16 -07:00
shadow-testandClaude Sonnet 5	61bdbc4a5b	Close the crash-window gap and exec-session leak a third review found ... A third Opus review pass confirmed round 2's fixes hold up, then found: - The pending-cleanup record `remove_project` writes is fully durable (fsync'd); the projects_store.remove() that follows it is a plain fs::write with no fsync. A crash or power loss in that window — or that store write failing outright, beyond what the previous round's in-process rollback catches — leaves a record on disk naming a project projects.json still lists as present. The very next startup retry would then delete that project's container, snapshot image, and both volumes (including the one holding the OAuth credential and every session transcript) out from under a project the user still sees in the sidebar. retry_pending_cleanup_logged now takes the ProjectsStore and refuses to touch — clearing instead — any record whose project id still exists. Also stopped swallowing the round-2 rollback's own failure. - Resolving the container through find_existing_container instead of project.container_id (round 2's stale-id fix) changed what drove close_sessions_for_container in remove_project and rebuild_project_ container: sessions are now leaked when Docker is unreachable (nothing resolves, so nothing closes, and the project record is gone a moment later) and in the stale-id race itself (sessions were opened against the container that actually exists, not the id find_existing_container bypasses). Both functions now close sessions for the stored id unconditionally, and again for the resolved id if it differs. - A pronoun-agreement bug in the no-retry removal toast ("remove them manually" for a single leftover) that was fixed one line above for verb agreement but not for the pronoun. Also closed the test gaps the review named: the pending-cleanup corrupt-record aside-move had no test, the Reset toast's leftover copy was inline and untested (extracted to lib/resetOutcome.ts, mirroring components/projects/home/removalReport.ts, with unit tests), and nothing asserted rebuild()'s success path maps outcome.project into the list rather than the whole outcome. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 09:47:45 -07:00
shadow-testandClaude Sonnet 5	439ef16f07	Fix two new bugs a second review found: stale container id, orphaned record ... A second Opus review of commit 2 found it had introduced real problems of its own rather than just polish gaps: - remove_project's "None or stale" container-id fallback only handled None. A stale id (the documented start-failure race in start_project_container_locked, where the old container is removed and the new one's id isn't persisted until after start_container succeeds) still 404'd on removal — now treated as success by commit 1's own fix — while the real container survived to block every volume removal with a 409 forever, with nothing in the pending-cleanup record ever naming it. Both remove_project and rebuild_project_container now resolve the container via find_existing_container() unconditionally, matching every other container-destroying path in the codebase, and remove_project fails closed (records a leftover rather than silently skipping) if Docker itself can't be reached to check. - remove_project could leave a pending-cleanup record for a project still live in projects.json: if the store's own save failed after the record was written, startup housekeeping would delete that project's container and volumes out from under it on the next launch. The record is now rolled back when the store write fails. - rebuild_project_container (Reset) only surfaced a leftover volume, not a leftover snapshot image — the more serious failure, since the next container is built from that image whenever it exists, silently reviving the exact system layer Reset was asked to discard. ProjectResetOutcome now carries leftover_image too, and the toast's "run docker volume rm" advice is corrected: the new container has already remounted the volume by the time the toast renders, so that command would just hit the same conflict Reset did. Also from the same pass: reworded a couple of log/toast lines that still asserted resources were "still present" when the daemon-unreachable case covered by the same code path can't actually confirm that; fixed a singular/verb mismatch in the leftover toast text; moved an unparseable pending-cleanup record aside instead of re-warning about it forever; and added a debug log when a record's recorded_at can't be parsed, so aging never silently no-ops. Pulled describeLeftovers/leftoverVerb out of ProjectHome.tsx into their own module with unit tests, and added tests for the recorded_at staleness check — the previous commit's equivalent logic had none. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 09:09:46 -07:00
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