447 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5.5	5b66e861df	feat(viewer): CodeMirror editor, theme and target-line highlight ... Implements Task 10 of the terminal file viewer plan: highlightLine.ts (line-range StateField + setHighlight effect), viewerTheme.ts (EditorView theme + syntax HighlightStyle), and CodeEditor.tsx (the React wrapper with getDoc/setDoc/goTo/focus). Also implements languages.ts + languages.test.ts, moved here from Task 7 per preflight ruling P1 (they need @codemirror/* packages, which only Task 6 installs). Preflight rulings applied: - P1: languages.ts/.test.ts live here, not in Task 7. - P12: syntax colours are `--syntax-*` custom properties in index.css, not hard-coded hex. - P13: languageFor tests assert `.not.toBeNull()` for mapped extensions and move README to the "returns null" case, instead of the vacuous `.resolves.toBeDefined()`. - P14(c): readOnly extension array factored into readOnlyExt(readOnly) instead of being duplicated in CodeEditor. - P16: no custom Mod-g binding; searchKeymap's Mod-Alt-g covers "go to line" already. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:12:05 -07:00
shadowdaoandClaude Opus 5.5	bbcaee7797	feat(viewer): poll and save scripts run as the container user ... poll.rs: one exec per tick that tests existence then hashes+stats the file (sha256sum/stat), so the 2 s poll costs one exec instead of re-downloading up to 1 MiB of archive per window per tick. write.rs: sha256_hex/is_sha256_hex, MAX_WRITE_BYTES, and the save script. Saving stages the payload in /tmp via the existing write_file_to_container (owned by the container user, since the Docker archive API writes as root), then an exec as `claude` checks the base hash, swaps the file in with a same-directory rename when the directory is writable (falling back to an in-place `cat >` when it is not), and always cleans up the staged temp file via `trap`. classify_write maps exit 0/3/4 to Saved/Conflict/Gone. Applies three pre-flight rulings against the brief's literal text: - P8: pulled the write script's argv shape and the size/hash checks into pure `write_command`/`check_write_input` helpers with their own unit tests, since both lived only inside the untested async `write_file` otherwise. - P9: the brief's manual Docker smoke-test invocation (`sh w.sh save target tmp hash`) makes `$1` become "save" instead of the target, which is not what the script or the Rust caller expect. Verified in a throwaway container that invoking the file directly without the dummy "save" arg reproduces the Rust convention's `$1/$2/$3` correctly: exit 0 with the new hash and a removed payload on a clean save, exit 3 with the file untouched on a stale base hash, and exit 4 when the target is gone. - P15: GNU sha256sum prefixes its output line with `\` when the path contains a backslash or newline. Without a fix that turns into a permanent false conflict (write.rs) and a blinded poll (poll.rs, hash: null forever). Both parsers now strip a leading `\`, and the script itself strips it from $actual before comparing to $expect. Verified against real sha256sum output in a container with a backslash-named file: the save no longer false-conflicts and the reported hash matches. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:11:19 -07:00
shadowdaoandClaude Opus 5.5	a80c146b8a	feat(viewer): second Vite entry, viewer capability, CodeMirror deps ... Task 6 of the terminal file viewer plan: app/viewer.html plus src/viewer/{main,ViewerApp}.tsx (placeholder ViewerApp for Task 11 to replace), registers viewer.html as a second Rollup input in vite.config.ts, adds the file-viewer capability restricted to file-viewer-* windows (allow-listen/unlisten for the goto event, allow-destroy for the close-button/prevent_close interaction, allow-internal-toggle-devtools to match default.json's dev convenience), installs the CodeMirror packages Task 10 builds languages.ts on top of (P1), and pins the viewer entry/capability with a Rust fallback-trap test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:08:01 -07:00
shadowdaoandClaude Opus 5.5	247ec764ea	feat(viewer): reload/conflict reducer and editability rules ... - viewerState.ts: pure reducer for the clean/dirty, same/changed/gone, container-down and overwrite-on-save states (spec §5), plus the pollEffect/canSave helpers EditorPane will drive off. - editability.ts: classifies a fetched file as text/image/binary and decides whether it is editable, deferring to Rust's readonly_reason when it refuses. Per preflight P1, languages.ts/.test.ts move to Task 10 (needs the CodeMirror packages Task 6 installs; out of scope for this task's worktree). Per P3, the "reloaded" action now carries `truncated` and `polledHash` so a poll-driven reload of a truncated (prefix-hash-only) file adopts the polled full-file hash instead of re-triggering a reload on every subsequent poll -- with a reducer test covering it. Per P13, tightened the poll_failed/canSave test to start from a dirty doc so it actually exercises containerDown rather than passing only because the doc was clean. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:07:28 -07:00
shadowdaoandClaude Opus 5.5	3177af202d	feat(viewer): pure file-path matcher for terminal text ... Adds findFilePathLinks, a pure matcher that finds file paths (with optional :line, :line:col, :start-end and #L42/#L40-L50 suffixes) in a line of terminal text, skipping anything inside a URL and stripping markdown/quote wrapping from the matched span. Per pre-flight ruling P7, a slash-having token still requires the basename to carry a real extension (any extension) or be a known extensionless basename -- a bare and/or or src/components is no longer treated as a path. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:06:52 -07:00
shadowdaoandClaude Opus 5.5	554870a50f	feat(viewer): candidate paths and container probe for the file viewer ... Implements resolve.rs: candidate_paths() turns a raw path Claude printed into an ordered, capped, deduped list of container paths (absolute paths pass through as-is; relative paths probe /workspace then each project mount, in order), PROBE_SCRIPT + parse_probe_output() run one exec that prints realpath -e of every candidate that is a regular file, and probe_candidates() wires the two together over exec_oneshot_streams_as. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:06:30 -07:00
shadowdaoandClaude Opus 5.5	d32dc9b446	feat(viewer): window registry with cap, dedupe and sequential labels ... Task 2 of the terminal file viewer plan: ViewerRegistry tracks which file-viewer-<n> window is looking at which container path. reserve() takes the cap check and label allocation atomically under one lock so two concurrent open requests cannot both slip past the 20-window cap; find_open() only matches windows in the Resolved state, so a window still choosing a candidate or reporting not-found is never treated as "open on" a path. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:05:33 -07:00
shadowdaoandClaude Opus 5.5	4ada54ffc4	feat(viewer): join wrapped xterm rows for link matching ... Adds joinWrappedRows/offsetToCell for reassembling a wrapped xterm line into its full text plus offset->cell mapping, so link matching can find paths that xterm has soft-wrapped across rows. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 21:05:06 -07:00
shadowdaoandClaude Opus 5.5	3c1d120305	feat(viewer): IPC types, wrappers and Rust module skeleton for the file viewer ... Task 0 of the terminal file viewer plan: the shared interfaces that seven later tasks build against in parallel. Adds ViewerLocation/ViewerTargetState/ ViewerState/ViewerFile/ViewerPoll to types.ts and their invoke() wrappers to tauri-commands.ts, creates the file_viewer Rust module (mod.rs with MAX_VIEWER_WINDOWS/VIEWER_LABEL_PREFIX/is_viewer_label, plus placeholder registry/resolve/poll/write/window submodules), wires it into lib.rs, and loosens visibility on the file_commands.rs helpers the viewer commands will reuse (MAX_READ_BYTES, validate_container_path, validate_container_write_path, FetchedFile, fetch_container_file, require_running, clip_container_text). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 20:56:33 -07:00
shadowdaoandClaude Fable 5.1	20befa1320	docs: terminal file viewer spec review and implementation plan ... Review the approved design against tauri 2.11.0, xterm 5.5.0, Vite 6.4.1 and the tree: record the verified multi-window, capability, CSP and exec facts, choose the save mechanism (stage in /tmp, swap in as the container user), make polling a sha256sum exec, store realpath-resolved targets, and pin the exact viewer capability set. Add the task-by-task plan with its parallel groups and the verification commands that work here. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-22 20:53:49 -07:00
shadowdaoandClaude Opus 5.5	508ff6d037	docs: design spec for per-window app-command lockdown via AppManifest ... Follow-up to the terminal file viewer spec. Verified against tauri 2.11.0, tauri-build 2.6.0 and tauri-utils 2.9.0 sources: with no app manifest the ACL skips app commands entirely; with one, every command must be granted to the calling window, unlisted commands are denied, and deny-* is global. The spec derives the manifest from generate_handler! in build.rs and fails the build when a command is missing from, or duplicated across, the capability files. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-22 20:39:38 -07:00
jknapp	3537b234d8	Make links in Claude's output clickable (#59) ... Reviewed three times. Rounds 1 and 2 each found a real hole in the gate -- a plain click opened links, then a selection gesture did -- both addressed. The attacker-controlled mouse mode is recorded as a known residual rather than claimed closed. Still unverified on a real desktop: double-click and drag-select across a link in both tracking states. v0.4.28-mac v0.4.28-win v0.4.28	2026-09-19 03:20:15 +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
jknapp	d647b56b43	Do not read an unreachable Docker daemon as an absent container (#58) ... Closes #56. Reviewed twice; the second round's findings on the first fix are addressed in f662ed0 and a3840f7. v0.4.27-mac v0.4.27-win v0.4.27	2026-09-19 02:59:20 +00:00
shadowdaoandClaude Opus 5	a3840f7263	fix: say which check failed, and stop claiming an order we do not use ... Two accuracy defects from re-review, both the same class as the bug this branch exists to fix. `probe_failed` rendered every failure as "This project's container could not be inspected", but only two of the four readings are about the container -- the others are the base image and the snapshot. A malformed base image name in settings therefore pointed the user at the wrong object. The sentence now names the check rather than the container. The doc claimed "the first error wins, in call order". It does not: the checks run container_id, base_image_id, container_running, while the daemon is called in a different order entirely. The priority is deliberate -- it puts the reading that stopped the probe first -- so the comment now says that, instead of describing an order the code does not use. The test guarding the first point asserted the message does not contain "Docker", using a synthetic payload. The real bollard error for that case is "Docker responded with status code 400: invalid reference format", so the assertion passed only because the payload was invented. It now uses the real shape and asserts what actually matters: that nothing we add claims the daemon was unreachable or names the container. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 19:53:52 -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	f662ed04ce	fix: a reading nobody consults must not destroy the report ... Review of this branch found the first cut made every probe error fatal, including one that is usually irrelevant. `snapshot_exists` is consulted only when there is no container, or when a stopped container coincides with a busy project -- `pick_probe_source` discards it outright for a running one. So a daemon hiccup between the four sequential readings turned a full report into a bare "could not be checked" with Update disabled, in a change whose whole purpose is handling exactly that hiccup better. It is now carried as a `Result` to the points that consult it and surfaced only there. `stopped_probe_policy` carries its own message, because "try again once it finishes" claims waiting is the only obstacle, which a failed `image_exists` has not established. `base_image_id` stays fatal, deliberately: it is the right-hand side of the comparison, and `image_id` already distinguishes "not pulled locally" (`Ok(None)`, a legitimate not-stale) from "could not ask". Letting an `Err` through as `None` would report a project up to date on a reading nobody got -- #56 one field over. The message no longer blames the daemon. Three of the four callees can `Err` from a daemon that answered perfectly: `image_id` maps only 404 to `Ok(None)`, and the base image name is user-supplied, so a malformed reference told the user to go fix a daemon that was running fine. That is the same category of error as #56 itself. `ContainerState` makes "running is known but no container was found" unrepresentable rather than merely unreached, so the downstream match has no impossible arm and the invariant is enforced where it is established. Finally, the tests covered the new function but not the line the bug was on: a partial revert to `.unwrap_or(None)` kept them all green. The readings now travel as a named struct of `Result`s, so that revert is a compile error -- verified by performing it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 19:38:31 -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	84a5757c74	fix: do not read an unreachable Docker daemon as an absent container (#56) ... `get_container_staleness` collected four probes through `unwrap_or`, so a transient daemon fault landed on the same arm as a genuine absence and the banner said, confidently and wrongly, that the project has no container or snapshot image to compare against. The four readings are now taken as `Result`s and funnelled through a pure `collect_probe_inputs`, following `pick_probe_source` and `stopped_probe_policy` in the same file, so the rule is unit-testable without touching Docker. The first error in call order wins and becomes `probe_error`; the command still returns `Ok`, because the hook's `catch` sets `staleness` to null and the banner returns early on null -- an `Err` here would hide the fault instead of reporting it. One of the issue's premises did not hold. `is_container_running` does not distinguish absent from unreachable: its body flattens every `inspect_container` failure to `Ok(false)`, so only a `get_docker` failure can surface as `Err`. Its `Result` is threaded through anyway, since that one case is a real daemon-unreachable signal and this layer no longer adds a second swallow on top, and the remaining gap is documented where the decision is made rather than patched in `docker/container.rs`, which the issue puts out of scope and whose doc comment says the swallow is deliberate. In practice `find_existing_container` runs immediately before and would already have errored if the daemon were down. No frontend change: `probeUnavailable` in ContainerMigrationBanner already routes a set `probe_error` to "Some checks did not complete". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 06:04:41 -07:00
jknapp	73a6e3d8b4	Merge pull request 'Make in-container OAuth logins actually complete' (#57) from fix/auth-callback-and-opener into main ... Reviewed-on: #57 v0.4.26-mac v0.4.26 v0.4.26-win	2026-09-18 04:32:07 +00:00
shadowdaoandClaude Opus 5	943c83b9e3	fix: stop a stale payload re-enabling a bridge the user turned off ... Review of this branch found that `update_project` restored `browser_view_enabled` from the store but took `auth_bridge_enabled` from the IPC payload, on a comment claiming the Config tab edits it through that save. The comment was wrong. `AuthBridgeRow` is the only writer, it calls `set_auth_bridge_enabled` out of band precisely so the switch works while a login is hanging, and it never writes the value back into frontend state -- so a payload's copy of that flag is always a stale snapshot. The consequence was not cosmetic: turn the bridge off, then close a renamed terminal tab, and `useTerminal` round-trips the stale `true` and the reconcile block restarts a bridge whose own UI warns that a bridged port is unauthenticated and reachable by any local process. Defaulting the flag to true earlier in this branch made it worse, since the stale value is now true for every pre-existing project. Both flags are now restored from the store by `restore_store_owned_fields`, and the reconcile block is gone rather than corrected: with the value always restored it could only re-assert what was already true, and every writer already owns its own side effect -- the setter starts and stops synchronously, container start arms the bridge, launch reconcile re-arms it, and the poller re-reads the flag each tick and self-terminates. Re-adding a start path to the one function that no longer owns the flag is what caused this. Turning the browser view off also stopped tearing the session down when the project record had vanished, because the persist used `?` and returned early -- the supervisor's own `store.get()` check exists because records do vanish mid-session. Teardown is now unconditional and the write error still surfaces afterwards, since the stored flag saying "enabled" means the view returns on next launch and that is worth reporting. Finally, the opener no longer falls through to `gio` on any non-zero exit. xdg-open's 1, 2 and 3 assert no handler ran; 4 also covers a handler that was launched and then failed, which would have opened the link twice -- two authorize requests for one click in an OAuth flow. Reasoned from documented exit codes rather than an observed double-open, and the cost is stated: a genuine code-4 failure no longer reaches gio. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 11:13:57 -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	db648230ee	chore: regenerate capabilities schema after dropping the opener grant ... Tracked build output; regenerated by the Tauri build from capabilities/default.json. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:11:03 -07:00
shadowdaoandClaude Opus 5	5a452e7a2a	security: drop opener:allow-open-url now that nothing calls it ... default.json carried this grant with an explicit accepted residual risk: a compromised webview could make the OS open an attacker-chosen http(s) URL. It was accepted because it could not be narrowed -- WebLinksAddon opens links Claude printed inside the container, which are arbitrary by construction, so a host allowlist would have deleted the feature. Now that every host-browser open routes through `open_url_external`, the webview has no reason to reach the plugin directly, and the risk closes rather than stays recorded. The plugin remains a dependency: macOS and Windows still use it, through `OpenerExt::open_url`, whose desktop implementation calls `crate::open::open` directly and is not gated by capabilities at all (tauri-plugin-opener-2.5.3/src/lib.rs:60) -- verified rather than assumed, since the whole point is that the Rust path keeps working. What is removed is the webview's ability to reach the opener without passing the Rust-side validation. The census note in default.json is rewritten to match, and lib.rs's grant-list test is updated deliberately, as its own assertion message demands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:10:45 -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	9297020688	fix: open host URLs with a clean environment (triple-c#34) ... On Linux the app ships as a single AppImage, and the AppImage environment leaks into everything it spawns. linuxdeploy's AppRun, linuxdeploy-plugin-gtk and our own wayland fallback hook all export LD_LIBRARY_PATH, GTK_PATH, GIO_MODULE_DIR and friends pointing inside $APPDIR, and main.rs sets WEBKIT_DISABLE_DMABUF_RENDERER process-wide for the webview. A browser that is already running shrugs this off, because xdg-open just hands the URL to the existing process. A cold-launched one inherits the lot and dies before painting -- with xdg-open still exiting 0, which is why this looked like the button doing nothing at all. `url_open` captures a pristine snapshot of the environment in main() before any mutation runs, then hands children a repaired copy: a saved original is restored where one exists, otherwise the process-start value is restored where we changed it, otherwise only the colon-separated entries that live under $APPDIR are dropped and the user's own are kept. Outside an AppImage it is a no-op. The command re-validates the URL in Rust rather than trusting the frontend, because the URL originates in an untrusted container: http/https only, no embedded credentials, no control characters or whitespace, length capped, ASCII asserted before it reaches execvp, and error messages never echo the input. Spawning is Command with explicit args and never a shell, trying xdg-open then gio open. No portal. org.freedesktop.portal.OpenURI would pull in a D-Bus client stack for one call on the one platform where we ship self-contained, and it only helps where a portal is running -- the same case where xdg-open already works once the environment is clean. `gio open` as a second candidate recovers most of the missing-MIME-association case for free. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:08:20 -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	90b7e4ccb2	fix: default the auth bridge on, and make the browser-view flag durable ... A CLI running `claude login` inside the container binds a random ephemeral loopback port and hands the provider a redirect pointing at it. The browser is on the host, so the callback lands on a closed host port and the login hangs with no diagnostic. The auth bridge is the thing that fixes this -- it mirrors container loopback listeners onto the same host port -- so having it default to off made a hang the out-of-the-box experience. `auth_bridge_enabled` now defaults to true through a `default_auth_bridge_enabled()` serde helper, matching the shape already used by `use_shared_auth_token`. Because the default is applied at deserialisation, projects stored before the bridge existed pick it up too; `migrate_from_value` writes neither flag, so nothing defeats it, and a regression test pins that. Separately, `BrowserViewManager.enabled` was in-memory only and the durable `browser_view_enabled` field on the project record was never implemented. Rather than sync the two, the cache is removed and the record becomes the single home for the flag, mirroring how `AuthBridgeManager` already works. `stop()` deliberately does not clear it, since container teardown and migration reach that path and neither is the user changing their mind. Durable does not mean auto-started: a restarted app reports enabled with the viewer off. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:06:09 -07:00
shadowdaoandClaude Opus 5	afe9d5cdb2	docs: correct Linux packaging in BUILDING.md ... BUILDING.md listed AppImage, .deb and .rpm as build artifacts, but Linux ships as AppImage only -- CI passes `--bundles appimage`, and the .deb and .rpm were dropped because neither could self-update. A bare `npx tauri build` still emits all three, since tauri.conf.json keeps "targets": "all" to leave macOS and Windows untouched, so the table now marks which are actually released rather than pretending the others do not exist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:01:29 -07:00
jknapp	b59c6148ff	Merge pull request 'Read a stopped container instead of claiming there is nothing to read' (#55) from fix/staleness-probe-stopped-container into main v0.4.25-mac v0.4.25-win v0.4.25	2026-09-11 03:54:40 +00:00
shadowdaoandClaude Opus 5	95a78fe9a3	Take the review: cache the stopped probe, and never let it cost an answer ... Six findings, all real. The one that mattered: `getContainerStaleness` is called from a `useEffect` that fires whenever the container settles, so merely opening a stopped project's Overview now committed its whole writable layer — 44 s on a real project, against ~3 s for the snapshot probe it replaced. Shipping that would have traded one bad banner for a bad page. A stopped container's writable layer cannot change, so the probe is exactly cacheable: `STOPPED_MANIFEST_CACHE` keys on the container's `FinishedAt`, which moves on every stop. Cold 2967 ms, warm 1 ms, measured. A live test asserts the restart case as well as the hit, because a cache that failed to invalidate would plan a migration against a filesystem the project no longer has — verified by breaking the token and watching that assertion fail. Skipping the probe for projects that are not stale looked like the cheaper fix and is unsafe: the deltas would be empty while `probeSettled` stayed true, and the migrate action in the project menu is not gated on the banner, so the pre-flight would report nothing to copy while the backend was told to copy nothing. That is the hazard `canMigrate`'s comment already warns about. Not done, and written down so it is not tried again. Also from the review: - A failed commit no longer costs an answer the snapshot could have given. Before this feature a stopped project read its snapshot directly, so surfacing this error would have made the banner worse than it was — and the failure modes are where the fallback earns its keep: a full disk (the commit allocates the whole layer, the snapshot probe allocates nothing) and a 409 from a concurrent claim. - The probe no longer commits while the project is claimed. The collision is not symmetric: the probe losing is a retryable `probe_error`, but `start_project_container` removes the old container with a hard `?`, so a remove that raced a commit would fail the user's Start with an opaque error. `stopped_probe_policy` reads `project_lock::held` and probes the snapshot instead, or defers with a message that says so. - The cleanup-failure warning claimed the next probe of the same container would reclaim the leftover. Unique names made that false the moment they landed; it is `reap_probe_images` that collects it. - The TS binding still called the command read-only, which is how the auto-refresh got added in the first place. - CLAUDE.md still documented the stable `triple-c-probe-{cid}:latest` name this PR removed as unsafe. 548 unit tests, 752 frontend tests, 4 live-Docker tests. Clippy unchanged at 44 warnings. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019RSaoDLovVV2wmH4H8VVxz	2026-09-10 20:48:10 -07:00
shadowdaoandClaude Opus 5	307ea07409	Read a stopped container instead of claiming there is nothing to read ... A project that was merely stopped reported "This project has no container or snapshot image yet, so there is nothing to compare against the base image" — with its container sitting right there — and Update stayed disabled. Start it and the checks passed, which is the tell: the staleness probe had only two sources, a *running* container via `docker exec` or the project's snapshot image. The snapshot is not a checkpoint. `commit_container_snapshot` runs only before a container is destroyed (a config-change recreate) or inside a migration, never on stop, so a project in daily use for a year can have no snapshot at all — and five of the six projects on the box that reported this had none. Absence of a snapshot was being read as absence of anything to inspect. So probe the stopped container directly: commit its writable layer to a throwaway image, probe that, drop it. A stopped container now also outranks the snapshot, for the same reason a running one already did — the snapshot lags it by everything installed since the last commit. `pick_probe_source` is the whole decision and is unit-tested; the message it used to emit now describes only the case it is true of, no container and no snapshot. Two things found on the way, both documented in CLAUDE.md: `bollard` never hands back the image id from a commit — its `Commit` model deserialises "ID" while the daemon sends "Id" — so the probe image has to be tagged, and a tagged image is dangling-proof and therefore invisible to `sweep_orphaned_snapshots`, `reap_stale_migration_pins` and `scrub_secrets_from_snapshots` alike. Without a reaper of its own a crashed probe would leak a multi-gigabyte image that nothing could ever reclaim, so `reap_probe_images` runs at startup beside `reap_probe_containers`, age-gated for the same reason that one is: `reference=` is daemon-wide and a second instance's live probe matches the glob. It removes by tag, never by image id: a force removal by id untags an image everywhere, which is how a first draft of the reaper test deleted an unrelated `alpine:latest`. Names are unique per call rather than stable per container, because container ids do not survive a recreate and two overlapping probes would otherwise fight over one tag. Verified against the container that reported the bug: 13,365 paths and an apt delta of cmake, ffmpeg, libobs-dev, qt6-base-dev and nine more — the migration payload the Update flow could not see. 546 unit tests plus three live-Docker tests pass; no new clippy warnings. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019RSaoDLovVV2wmH4H8VVxz	2026-09-10 19:24:05 -07:00
jknapp	37bbf181c9	Merge pull request 'Give the mouse back, retire the follow controls, update Claude per session' (#54) from feat/mouse-release-retire-follow-update into main v0.4.24-mac v0.4.24-win v0.4.24	2026-09-08 23:43:34 +00:00
shadowdaoandClaude Opus 5	5d16b5713d	Give BuildKit the host's network, so it can reach the runner's cache ... The multi-arch build needs the `docker-container` driver — the plain `docker` driver cannot do linux/amd64+linux/arm64 — and that driver runs BuildKit in its own container on Docker's default bridge. act_runner advertises ACTIONS_CACHE_URL as an address the *job* container can reach, and nothing teaches the BuildKit container about it. So the job could reach 192.168.1.126:40649 while the container actually making the cache request could not. That is also why no other workflow here hit this: it is the only one using buildx. The rest make their cache calls from the job container act_runner set up. `no route to host` is EHOSTUNREACH — a firewall rejecting, not a missing route — which is what a default firewalld zone does to traffic from the docker bridge, and the runner registers under the stock RHEL/Fedora hostname. Sharing the host's namespace sidesteps it: the cache address becomes local to BuildKit. No effect on runners where this already worked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0145mQi9NZiCDrznBUEEDE4n	2026-09-08 15:30:27 -07:00
shadowdaoandClaude Opus 5	c02c02cbfc	Never fail a container build because the cache was unreachable ... Every layer of both architectures built. The job then died exporting to act_runner's emulated GitHub Actions cache service, which it could not route to: `GetCacheEntryDownloadURL ... dial tcp 192.168.1.126:40649: no route to host`. On a pull_request `push:` is false, so this job pushes nothing and the cache is its only output — which means a network problem between the buildx `docker-container` builder and the runner host threw away a complete, successful validation of the Dockerfile on linux/amd64 and linux/arm64. A cache is an optimisation; it must degrade to "slow", never to "red". Only the exporter needs the flag. The import is already non-fatal — the build ran all 37 layers after warning it could not read the cache. This does not fix the routing itself, so builds stay uncached until that is sorted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0145mQi9NZiCDrznBUEEDE4n	2026-09-08 12:48:41 -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
jknapp	3aec2998d8	Merge pull request 'Anchor the update channel tag, and stop shipping a duplicate AppImage' (#52) from fix/update-channel-durability into main v0.4.23-mac v0.4.23 linux-latest v0.4.23-win	2026-09-03 16:52:47 +00:00
shadowdao	019fb403d5	Merge remote-tracking branch 'origin/main' into fix/update-channel-durability	2026-09-03 09:41:22 -07:00
jknapp	b21a568bf5	Merge pull request 'Install from the lockfile, so CI cannot be broken by someone else's release' (#53) from fix/ci-npm-lockfile into main v0.4.22-mac v0.4.22-win v0.4.22	2026-09-03 16:41:15 +00:00
shadowdaoandClaude Opus 5	f41b1d9054	Install from the lockfile, so CI cannot be broken by someone else's release ... `build-linux` fails before `tauri build` runs, on every workflow, at "Install frontend dependencies": npm error Cannot read properties of null (reading 'edgesOut') Reproduced exactly on the first attempt by running the step's own commands locally on the same Node 22.23.2 the runner installs. The debug log gives the frame the CI output omits: at #loadPeerSet (.../@npmcli/arborist/lib/arborist/build-ideal-tree.js:1289:38) It is a null dereference in npm 10.9.8's peer-set resolver, reached through vite → @vitejs/devtools → @vitejs/devtools-vitest → vitest@* → @vitest/browser-playwright → vitest@4.1.11 → jsdom@* → canvas. **Nothing in this repo changed to cause it.** The step deleted `package-lock.json` before installing, so every build re-resolved the entire tree against the registry against ranges like `vitest@*`. A dependency published a version that produces a peer graph npm cannot resolve, and our CI broke — the same command succeeded fifteen hours earlier for 0.4.21. That is the real defect: the build was never reproducible, and the crash is only how we found out. So Linux installs with `npm ci`, from the committed lockfile, like Windows already did. macOS moves too — it kept the lockfile but still ran `npm install`, which is free to re-resolve; all three platforms now install identically and none can re-resolve mid-release. **The reason the lockfile was being deleted is obsolete, not ignored.** 2d4fce9 removed it "to ensure correct platform-specific bindings", which was a real problem once. The committed lockfile now records 25 rollup platform variants, and `npm ci` on Linux installs precisely rollup-linux-x64-{gnu,musl} and @esbuild/linux-x64 — checked directly. A comment on the step says so, and says not to reach for deleting the lockfile again: if `npm ci` refuses, package.json and the lockfile have genuinely diverged and the fix is to commit an updated lockfile. Verified from the resulting tree: `tsc --noEmit` clean, `npm run build` successful, 752 tests across 62 files passing. The `npx tauri --version || npm install @tauri-apps/cli` fallback in the next step cannot reintroduce a fresh resolution — the CLI is a pinned devDependency that `npm ci` installs, so the fallback is unreachable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-03 09:28:09 -07:00
shadowdaoandClaude Opus 5	d38736007f	Take the re-review: distinguish "absent" from "unreachable" ... Second review of this branch. Two blockers and one real defect I had papered over with a true-but-misleading claim. **`make_latest` was missing from the republish path.** The create path sends `"make_latest": "false"` so the channel cannot displace the versioned release on the releases page. The reuse path — taken on every run after the first — omitted it, and the API's documented default for a publish transition is `true`. So the second release would have quietly promoted `linux-latest` to the repository's Latest release: a release whose own body says "for a specific version, use the versioned releases instead". Now sent on both paths. `tag_name` is re-sent deliberately and now says so in a comment — the API removes the tag when a PATCH omits it, and this branch exists because a tag disappeared. **A transient Gitea error would have cost the whole release.** `curl -sf` fails identically for "404, the tag is genuinely absent" and "503, Gitea is briefly unreachable", and both landed in the create branch. Creating a tag that already exists returns 409, which aborted the last step of `build-linux` — and `create-tag` and `sync-to-github` both depend on it, so no version tag and no GitHub sync at all. The failure message also read "the tag does not exist" when Gitea had merely been unreachable. Now a `case` on the HTTP code — 200 leave alone, 404 create, anything else fail loudly with the real code — the same idiom `Upload to Gitea release` already uses two steps above. `422 already_exists` on the release POST is likewise a recoverable answer, not a reason to lose a release. **The empty `Categories=` was still shipping, and my claim hid it.** I wrote that the guard "asserts the absence of an empty value rather than the presence of any filled one" — true of the regex, false of the artifact. The AppDir root `.desktop` is a *symlink* into usr/share/applications, so `sed -i` replaced the link with a regular file and left the real entry empty; the guard globbed the root only, so it saw the copy it had just written and passed. Verified on the real artifact: two divergent entries, and the one that shipped was empty. Fixed with `--follow-symlinks`, both locations globbed, and the guard turned into a positive assertion over every entry — which also closes its missing-key and unmatched-glob holes. Both entries now read `Categories=Development;Utility;`. Also taken: the duplicate-AppImage check moves to a precondition, since as a post-mortem it let the script repack and overwrite the versioned artifact before failing, and it silently selected by glob order, i.e. the older version — it now refuses in under a second; assets are deleted and re-uploaded one at a time, because deleting both up front left a fresh AppImage with no .zsync if the second upload failed, which silently stops every client; and the success line no longer claims a fallback was kept when there was nothing to demote. Left as informational, with the reasoning recorded rather than acted on: `--retry-all-errors` retries permanent 4xx (fail-closed, matches the repo's other upload steps); the release list is unpaginated (a GraphQL lookup by pending tag name is the durable fix, but 7 releases is decades from the cliff, and the 422 handling above covers the failure mode); process-substitution failure is invisible to `mapfile` (fail-closed downstream). Verified against the real 0.4.19 artifact — happy path, no AppImage, two AppImages, and an AppDir rebuilt with the bundled library removed. shellcheck clean at warning level on both scripts. appimagetool now reports the AppStream metadata found. Nothing here is CI-proven, and that is worth stating plainly: `build-linux` fails on this branch before `tauri build` even runs, at "Install frontend dependencies" with `npm error Cannot read properties of null (reading 'edgesOut')` — confirmed in the logs of jobs 5644 and 5636. Unrelated to this change and tracked separately, but it means the finalizer has never executed in CI on either commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-03 09:17:34 -07:00
shadowdaoandClaude Opus 5	63f282bef6	Fix the review findings: never destroy a working anchor ... An adversarial review of the previous commit found six real problems and corrected one of my claims. Taking all of it. **The anchoring could kill the channel it exists to protect.** It did DELETE-then-POST so the tag would name the current build. If the POST failed for any transient reason the script aborted having already deleted the anchor a previous run put there, and the next mirror run pruned GitHub's copy — a transient Gitea error converting a healthy channel into a dead one, which is strictly worse than the step not existing. There was also a real window between the two calls with no tag at all. The DELETE bought nothing. The update string resolves the tag by *name* and the assets hang off the release object, so nothing about the channel depends on which commit the tag points at; moving it changes only the source-zip link. It existed solely to get past a 409, since Gitea's POST /tags has no force semantics. Now the tag is created if absent and otherwise left alone, which removes the window too. **My "no window where the two disagree" claim was wrong, and it is the third time in this area I have asserted something I had not established.** The release POST sets no `target_commitish`, so GitHub creates its tag at its own default-branch HEAD, not at `GITEA_SHA`; the two agree only because `sync_on_commit` pushes main minutes earlier. And the DELETE actively created the window. What the ordering genuinely buys is narrower: if anchoring fails, the script aborts before creating a GitHub release that would be orphaned. **Orphaned drafts were invisible to the release lookup.** GitHub demotes a release to a draft when its tag is deleted, and `/releases/tags/` never returns drafts — precisely the state every mirror run left behind. The by-tag lookup reported "absent" while 86 MB drafts accumulated, one per release. The lookup now reads the authenticated list, republishes the newest, and deletes the rest. **A guard that could not catch what it named.** The update-info assertion was a substring match on the tag, so it passed for a wrong host, path, filename or transport — verified: an `evil.example.com/.../linux-latest/...` string passes the old check and fails the new one. Now a fixed full-string match. Also from the review: an absent bundled library no longer exits early, because that skipped the metadata *and* left `update-channel/` uncreated, killing the publish step on a missing directory and taking the tag and mirror jobs with it; the Categories guard asserts the absence of an empty value rather than the presence of any filled one; the channel directory is cleared before use so a stale zsync cannot satisfy an existence check while describing the previous build; the AppImage count uses a glob array, since `ls | wc -l` aborted under pipefail before the message it promised could print; uploads carry the retry/http1.1 hardening this repo's other upload steps already learned to need; verification compares served size against built size, because a status code only proves something is served; and the release workflow now fails on empty artifacts instead of publishing a release with no AppImage. The metainfo file is installed as `Triple-C.appdata.xml`. appimagetool derives the name it looks for from the .desktop basename, so under the id-based name it warned the metadata was missing on every build while this script reported it present. Now it prints "AppStream upstream metadata found in usr/share/metainfo/Triple-C.appdata.xml" — the AppStream id inside the file is unchanged and is what identifies the component. Two review hypotheses did not hold and nothing was changed for them: `set -e` does not abort on a failing `&&` list mid-script, and my claim of a `trap` reassignment was wrong — there is one trap, installed once. Verified against the real 0.4.19 artifact: exit 0, one AppImage beside the release, channel pair in its own directory, appimagetool reporting the metadata found, and the wayland fallback intact. Guards exercised individually — the duplicate one bites, the exact-match one rejects an impostor carrying the tag, the empty directory reports cleanly, and all four publisher preconditions refuse rather than half-publishing. Header parsing for the size check was tested against a real redirecting GitHub asset URL. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-03 08:53:13 -07:00
shadowdaoandClaude Opus 5	d561ce03d5	Anchor the update channel tag, and stop shipping a duplicate AppImage ... Two defects in the update channel, both visible in 0.4.20 and 0.4.21. **The channel tag does not survive.** `publish-update-channel.sh` created the GitHub release, uploaded both assets and verified each URL returned 200 — the job log shows it succeeding at 00:38. By 13:04 the tag was gone and every installed copy was checking a 404. Gitea push-mirrors this repo to GitHub every four hours, and a mirror push deletes remote refs with no local counterpart. `linux-latest` was created by GitHub's release API and never existed as a Gitea tag, so the mirror removed it. Versioned tags were never affected because `create-tag` creates them in Gitea first. So the tag is now anchored in Gitea, and before the GitHub release rather than after, so there is no window where the two disagree. Its absence fails the step instead of warning, because it is the only thing keeping the channel alive. Worth stating plainly: publishing correctly is not evidence the channel still works, and the verification that passed at 00:38 could not have caught a failure that arrives twelve hours later. **Every release carried the AppImage twice.** The channel's stable-named copy sat beside the versioned one, where the release job's `*.AppImage` glob picked it up — so v0.4.21 published `Triple-C_0.4.21_amd64.AppImage` and `Triple-C_x86_64.AppImage`, byte-identical at 86,686,200 bytes each, and `sync-to-github` copied both to the mirror. 80 MB of duplicate per release, under a name that reads like a different build. That is how it was noticed. The channel pair now lives in `bundle/appimage/update-channel/`, out of the glob's reach, and a guard fails the build if more than one AppImage is left beside the release. Verified by planting a second one: it fails. One appimagetool quirk found while moving it — zsyncmake writes the .zsync into the working directory, not beside the image it describes, so it has to be collected rather than assumed in place. The existing guard caught that too. Verified against the real 0.4.19 artifact: exactly one AppImage at top level, the channel pair in its own directory, update string still resolving to the fixed tag, and the wayland fallback intact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-03 08:29:58 -07:00
jknapp	670450ccfd	Merge pull request 'Make the AppImage updatable, and drop the deb and rpm' (#51) from feat/appimage-update-metadata into main v0.4.21-mac v0.4.21-win v0.4.21	2026-09-03 00:28:10 +00:00
jknapp	a0b9f1e19b	Merge pull request 'Let the host's libwayland-client win in the AppImage' (#50) from fix/appimage-wayland-client into main ... Reviewed-on: #50 v0.4.20-mac v0.4.20-win v0.4.20	2026-09-03 00:22:03 +00:00
shadowdaoandClaude Opus 5	9fadfbc37a	Make the AppImage updatable, and drop the deb and rpm ... An AppImage manager can adopt the current build but never update it: the image carries no update information, which is the string that tells such a tool where to look for a newer one. It also carries no AppStream metadata, so a manager has nothing to show but a filename — appimagetool has been warning about that on every build — and linuxdeploy leaves `Categories=` empty, which files the app nowhere in a desktop menu. All three are fixed while the image is already unpacked for the wayland fix, so the cost is a few lines rather than a second pass. `unbundle-wayland-client.sh` is now `finalize-appimage.sh`, since it does more than unbundle. The update URL is a **fixed** `linux-latest` tag on the GitHub mirror, which is where updates are pulled from — deliberately not `releases/latest`. `latest` follows whichever release is newest, and the Gitea-to-GitHub backfill creates one GitHub release per Gitea tag, including the `-win` and `-mac` tags that carry no AppImage. A URL that can resolve to a release with no AppImage in it fails on users' machines and nowhere else. The output is named for that tag too, and that is not cosmetic: zsync records a *relative* filename which a client resolves against the .zsync URL it fetched, so a versioned name would send every client after the build it already has. Verified by reading the generated header — `Filename: Triple-C_x86_64 .AppImage` — and the image's own `.upd_info` section, which is where the tag actually lives. My first guard checked the .zsync for the tag and failed correctly, which is how that distinction got found rather than shipped. Range requests were confirmed against the mirror before building on them: 206 with a correct content-range, so updates are real deltas rather than an 85 MB re-download. The .deb and .rpm go. They are two more artifacts to build, publish and keep working for an audience already served by the one file that runs on every distribution, and neither could ever self-update — which is now the difference that matters. Older releases keep theirs. The Linux job passes `--bundles appimage` rather than changing `tauri.conf.json`, so macOS and Windows are untouched. Verified against the real 0.4.19 artifact: it repacks, the AppStream file and filled-in Categories land inside the image, the update string resolves to the fixed tag, and the wayland fallback still holds. Both publisher failure paths refuse rather than half-publishing — no token, and missing artifacts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 17:10:44 -07:00
shadowdaoandClaude Opus 5	a3bdf6f4da	Let the host's libwayland-client win in the AppImage ... The AppImage came up blank on CachyOS with `Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...`, and the DMA-BUF workaround already in `main.rs` did not help — verified by finding the flag compiled into the shipped 0.4.19 binary, where it runs unconditionally on Linux. It is a different fault with the same error text. linuxdeploy bundles `libwayland-client.so.0` as a GTK dependency and `AppRun.wrapped` puts the bundled directory ahead of the host's, so the host's Mesa resolves against our copy. `libEGL_mesa.so.0` — the driver libglvnd's `libEGL.so.1` dlopens — has a hard DT_NEEDED on that library, so when its symbols will not resolve the driver never loads, glvnd is left with none, and `eglGetDisplay` reports no display. That is why `GDK_BACKEND=x11` does not dodge it, and why the symptom is a bad-parameter error rather than a link failure. Bisected on the reporter's machine against the released artifact — removing `libwayland-client.so.0` from the AppDir cleared the abort, while removing `libwayland-egl` or `libepoxy` did not. The bundled copy (Ubuntu 22.04, wayland 1.20) is missing eleven symbols their wayland 1.26 exports, including `wl_proxy_get_display`, `wl_proxy_get_queue`, `wl_display_create_queue_with_name` and `wl_fixes_interface`. Bundling a newer wayland would defer this, not fix it: the floor is set by the host's Mesa, which updates independently of our releases, so any version we pick is one release away from being too old again. This is a host-coupled library like libGL and libdrm — the only correct version is the host's. So the copy is demoted rather than deleted. It moves off the loader path into `usr/lib/wayland-fallback`, and a hook adds that directory back only when the host has no libwayland-client of its own — so a host without one still starts. The ordering is safe because `AppRun.wrapped` appends the inherited LD_LIBRARY_PATH after its own entries, making the hook a fallback and never an override. AppRun sources hooks by name rather than globbing, so it is patched to source this one. X11-only hosts are unaffected: libwayland-client is a package dependency of Mesa and GTK, so it is present even on a machine with no display server at all — confirmed on a headless container with neither DISPLAY nor WAYLAND_DISPLAY set. And the AppImage already runs as an X11 client everywhere, since linuxdeploy's own hook forces GDK_BACKEND=x11. Verified against the real 0.4.19 artifact rather than a synthetic AppDir: it repacks, the binary and AppRun survive, and both hook branches were exercised — host-has-it leaves LD_LIBRARY_PATH untouched, and a debian:12-slim container with no wayland at all engages the fallback. The comment in `main.rs` quoted this exact error as one the DMA-BUF flag fixes. That claim sent this investigation down the wrong path first, so it is corrected rather than left to do it again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 16:57:51 -07:00
jknapp	dc9cdd1760	Merge pull request 'Add a per-project Notes tab with a send-to-agent action' (#48) from feat/project-notes into main v0.4.19-mac v0.4.19-win v0.4.19	2026-09-02 20:42:07 +00:00