261 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
jknapp	01e72e4785	Merge pull request 'Let a project's container run a VPN client' (#27) from feat/vpn-support into main v0.4.8-mac v0.4.8 v0.4.8-win	2026-08-14 15:30:03 +00:00
shadow-testandClaude Opus 5	2b35aa8c16	Explain a missing tun device where the failure actually happens ... Review caught that the device guard was wired to the wrong call. The daemon does not resolve `--device` at create: verified against Docker 29.7, `docker create --device /dev/does-not-exist` succeeds and prints an id, and runc only resolves the device — and validates sysctls — when it builds the container. So on a host with no tun module the create returns fine and `start` fails, which means the explanation never ran and the user saw the raw daemon string naming a path they would go looking for on the wrong machine. The unit tests fed the create-side string straight in, so they confirmed a function no real failure could reach. Move the guard onto `start_container`, covering create as well in case a future daemon checks earlier. It no longer takes `vpn_support_enabled` — `start_container` has a container id and no project, and nothing else in Triple-C ever requests a device, so an error naming /dev/net/tun is unambiguous on its own. The test now uses the daemon's verbatim message via bollard's real Display format. Also from review: * Soften the security claim. Docker does not enable user-namespace remapping by default, so this is a real CAP_NET_ADMIN in the initial user namespace with only the network namespace confining it. It cannot touch host interfaces, but "confers no authority outside the container" was too strong: within its namespace it can set promiscuous mode and add addresses, routes and NAT on the shared docker0 segment, which puts sibling containers — the LiteLLM gateway among them — within ARP-spoofing reach, and it can flush netfilter rules sandbox mode may rely on. Said plainly in the code, CLAUDE.md and HOW-TO-USE. * Drop Tailscale from the list of clients needing this. Its --tun=userspace-networking mode needs neither the capability nor the device, and listing it invites granting NET_ADMIN for nothing. * Say in the toggle's own hint that changing it recreates the container, matching how every other recreation-triggering setting is labelled. The tab's generic "stop the container first" chip does not tell the user what is about to happen. * Add RuntimeSection tests: saves on, saves off explicitly rather than dropping the key, reflects state, is disabled while running, and carries the recreation warning. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> preview-2b35aa8	2026-08-14 08:15:05 -07:00
shadow-testandClaude Opus 5	65a3d4eb29	Let a project's container run a VPN client ... A VPN client installed in a container today starts, runs, and then hangs until its connection times out. Nothing reports an error: a default container has no /dev/net/tun to open and no CAP_NET_ADMIN to add an interface or a route with, and clients surface that as a generic timeout rather than a permissions failure. Add an opt-in per-project "VPN support" switch granting the three things a tunnel needs. They are useless individually, which is why vpn_host_config() defines the set in one place and the tests assert all of it: * CAP_NET_ADMIN — Docker's default bounding set has net_raw but not net_admin, so a client can ping but never connect. * /dev/net/tun — passed through from the host so the kernel's tun module backs it, rather than mknod-ed inside. * net.ipv4.conf.all.src_valid_mark — WireGuard's wg-quick sets this and cannot from inside a container, /proc/sys being read-only, so its handshakes are dropped by reverse-path filtering. Off by default and deliberately opt-in: NET_ADMIN lets anything in the container reconfigure that container's network stack. It is namespaced — no authority over the host's interfaces or any other container. Capabilities and devices are fixed when a container is created, so this is container state and takes the label-and-compare treatment. triple-c.vpn-support is written unconditionally, false included, for the usual docker commit reason: a true stamped once would ride the snapshot image into every future container and make the switch impossible to turn back off. A missing label reads as false and off is byte-identical to today, so no existing project is churned. Requesting the device fails at creation when the host kernel has no tun module, which would otherwise surface as a project that simply refuses to start. explain_create_failure() rewrites that one error to name the switch and the Docker-Desktop-VM-versus-your-machine distinction, and leaves every other failure untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> preview-65a3d4e	2026-08-14 08:06:39 -07:00
jknapp	2b2d9da606	Merge pull request 'Number releases by the highest one already published, not by drift' (#26) from fix/monotonic-release-version into main v0.4.7-mac v0.4.7-win v0.4.7	2026-08-14 06:00:50 +00:00
shadow-testandClaude Opus 5	3741e0fef5	Number releases by the highest one already published, not by drift ... The Linux release upload failed with a bare "exitcode '1'" and no output. The cause was not the upload: compute-version handed it a version that had already been released three days earlier. The patch number was `git rev-list --count <highest tag>..HEAD` — how far HEAD has drifted from whichever tag sorts highest, which resets to zero every time a tag is cut. It is not a counter, and the published history is what the old formula returned at each point: v0.4.0 -> 3 commits -> v0.4.3 looked fine v0.4.3 -> 4 commits -> v0.4.4 fine by luck, 4 > 3 v0.4.4 -> 2 commits -> v0.4.2 went backwards v0.4.4 -> 6 commits -> v0.4.6 jumped, skipping .5 v0.4.6 -> 3 commits -> v0.4.3 already taken So the line published 0.4.0, 0.4.3, 0.4.4, 0.4.2, 0.4.6 in that order, never used 0.4.1 or 0.4.5, and then came back round to 0.4.3. The patch is now one past the highest already used. Suffixed tags count towards that: create-tag is skipped whenever a platform job fails, so a run can publish v0.4.7-mac and never create the plain v0.4.7, and reading only unsuffixed tags would hand the same number out twice. A commit that is already tagged reuses its own tag, so re-running a build does not mint a version. Reusing a number was doing real damage, not just failing. macOS and Windows delete-then-upload each asset, so they took the duplicate in their stride and rewrote v0.4.3-mac and v0.4.3-win — public since Aug 11 — with today's binaries. Linux is the only platform that failed, and failing was the correct outcome; its v0.4.3 assets are the only ones still original. Linux also gets the idempotent get-or-create the other two already had, plus `set -euo pipefail` and `-fsS`. Its `curl -s` with no `-f` is why a 409 produced no diagnostic at all: the HTTP error was swallowed, the id grep came back empty, and the step died without ever printing why. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 22:57:36 -07:00
jknapp	0e6566d903	Merge pull request 'Fix Playwright setup destroying its own install, and the migration notice that stayed silent' (#25) from fix/playwright-container-setup into main	2026-08-14 04:34:20 +00:00
shadow-testandClaude Opus 5	84a67fcd0d	Stop an empty base-image label from silencing the migration notice ... A project can be out of date and say nothing about it, in two ways that compound: the lineage lookup treats "unknown" as an answer, and the fallback that exists for unknown lineage disappears when its probe fails. `create_container` always writes triple-c.base-image-id, even when the value is unknown — deliberately, so an inherited image label cannot ride a snapshot forever. That makes Some("") the ordinary reading from a container whose lineage was never established. The lookup filtered for emptiness only on the final result, so that empty string satisfied the container branch and skipped the snapshot entirely: a snapshot that had recorded a real lineage was never consulted, and the project reported "unknown" with the answer one lookup away. Each source is now filtered before it can answer, in pick_recorded_lineage, which is a plain function so the case has a test that fails against the old logic. A genuinely pre-label project stays unknown, and should: its ancestor is not knowable, and inventing one would make it look permanently current. The probe is the intended signal for those — but if the probe failed, get_container_staleness returned early with nothing populated, the banner found no gaps and rendered null, and the probe_error it already knew how to display sat behind a gate that returned before reaching it. Silence there is indistinguishable from "up to date", and it is likeliest for the oldest and largest projects, whose manifests are the ones apt to exceed the inspection limit — one real project measured 6.93 MB against an 8 MB cap. An unknown-lineage container whose probe failed now says the check could not be completed, with the reason, under the tone that means unresolved rather than the one that means something is wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 21:24:51 -07:00
shadow-testandClaude Opus 5	f3cc1c4c17	Stop Playwright setup from deleting the package it just installed ... Setting up the browser view failed on every container, and re-running it reproduced the same broken state, because the setup destroyed its own work. `install_packages` ran two `npm install --no-save` commands into /workspace, which has no package.json. With no manifest, npm treats the command line as the whole statement of what the tree should contain and prunes the rest, so installing `playwright` second removed the `@playwright/cli` installed first: "removed 3 packages", leaving an empty node_modules/@playwright/ behind playwright and playwright-core. That empty directory is exactly what the pane then reported as missing. The second install now names both specs; the first one is already present, so it costs nothing and is only there to stop npm pruning it. Two failures were waiting behind that one: Nothing in the tree ever configured the browser, so playwright-cli fell back to channel `chrome` — system Google Chrome — with the Chromium sandbox on. These containers forbid unprivileged user namespaces, so it aborted with "Failed to move to new namespace ... Operation not permitted"; on a base image without Google Chrome the same default failed as "Chromium distribution 'chrome' is not found". entrypoint.sh now seeds ~/.playwright/cli.config.json on every start, which is the only way to reach existing projects: ~/.playwright is inside the home volume, so an image copy would reach new projects only. The launch check passed for a configuration the viewer never uses. It launched bundled chromium with no channel, which resolves to chromium-headless-shell, while the viewer's config pins chrome-for-testing — the full chromium build, a separate download. A container could pass every check and still fail in the pane with 'Browser "chrome-for-testing" is not installed', which is what a stale chromium-1217 against a wanted chromium-1237 did. Chromium is now verified on both channels, the sandbox setting is stated rather than inherited from a default, and a failure names the channel. triple-c-playwright-heal repairs all of it on a container that is already broken, including the missing socat that makes the pane report "127.0.0.1 sent an invalid response" while the container side is perfectly healthy. It verifies by launching a browser rather than trusting the preceding steps — which is how the stale-revision case was found — and lives in /usr/local/bin so a fix to it can still reach an existing project. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 21:24:37 -07:00
jknapp	7265f55f27	Merge pull request 'Fix scheduled tasks failing to authenticate, and show when one is running' (#24) from fix/scheduler-home-clobber into main ... Reviewed-on: #24 v0.4.6-mac v0.4.6-win v0.4.6	2026-08-12 13:55:54 +00:00
jknapp	88f2e73474	Merge branch 'main' into fix/scheduler-home-clobber	2026-08-12 13:55:37 +00:00
shadow-testandClaude Opus 5	fa4940dd7d	Say when a scheduled task is running ... A run is detached — cron has no terminal, and the app fires it as a detached exec — so triggering one and watching the log was indistinguishable from triggering one that died. Worse, `claude -p` writes its answer in a single burst at the end, so a healthy run shows nothing but its log header for as long as it is thinking. The honest reading of the old UI was "it stalled". triple-c-task-runner now publishes a state file per run (pid, start time, log path) and removes it from an EXIT trap. flock remains what actually prevents overlapping runs; this is purely observability, so every reader verifies the pid rather than trusting the file — a container stopped mid-run cannot fire a trap, and a task stuck on "running" forever would be a worse lie than no indicator at all. Stale files are cleared on read. On top of that: - `list` grows a status column: "running 4m12s" or "idle". - `status [--id] [--watch]` answers "is it still going?" directly, with elapsed time and the tail of the log when there is any output yet. - `run` streams the log instead of blocking silently, and refuses to start a task that is already running. - The Automation tab marks a running task, disables its Run now button, and polls while anything is in flight — including the second or two between firing a run and the runner registering it, which is the exact window that used to read as dead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 06:33:49 -07:00
shadow-testandClaude Opus 5	9027fa9ad4	Stop the scheduler handing Claude root's HOME ... Every scheduled task failed with "Not logged in · Please run /login" while the container's OAuth credential sat there, valid, the whole time. The entrypoint snapshots the environment into ~/.claude/scheduler/.env so cron jobs get more than cron's minimal env. It runs as root, and HOME was in the capture list, so the file recorded HOME=/root. The task runner then sources that file with `set -a`, overwriting the HOME cron gave the job. `claude -p` looks for its credential under $HOME, finds no /root/.claude, and exits 1. Logging still worked — SCHEDULER_DIR is expanded before the sourcing — which is why this presents as a well-formed log of a task that never authenticated. Drop HOME from the captured set and write it explicitly instead; cron does still need one. Then restore HOME across the source in the task runner too: .env lives on the home volume, so every project created before this ships keeps a stale copy of it until its container restarts, and the runner is what has to survive that. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 06:13:59 -07:00
jknapp	be37723c38	Merge pull request 'Sweep the snapshot commits recreation leaves behind' (#23) from sweep-orphaned-snapshots into main ... Reviewed-on: #23 v0.4.2-mac v0.4.2-win v0.4.2	2026-08-12 02:06:24 +00:00
shadow-testandClaude Opus 5	5f990dd28b	Sweep the snapshot commits recreation leaves behind ... Every recreation commits the container to triple-c-snapshot-{id}:latest and moves that tag; the image it pointed at keeps its layers and loses its name. Nothing deleted those, so they accumulate — measured on one real host, 7 orphans holding 7.4 GB, three of them from a single day's work. `sweep_orphaned_snapshots` removes them, under two conditions that are the whole safety argument. Untagged: every image the app depends on carries a tag, so a project's live `:latest` and a migration's `pre-migration-*` rollback pin cannot match the filter at all. And labelled `triple-c.managed=true`, which `docker commit` copies from the container onto the image — the user's own dangling images are not ours to delete. Removal is unforced on top of that, so Docker refuses while any container is still built from the image, including the stopped containers of projects that are not running; those are counted and left for the next sweep. It runs after a recreation, which is when the orphan it just made becomes removable, and after a migration is accepted, which is the moment dropping the pin turns the pre-migration snapshot into an orphan. Both detached: this is housekeeping, and a full disk beats a project that will not start. Each sweep clears every orphan it finds, so recreations that predate it are cleaned up too. The label string is now a constant rather than four literals, and a test pins both filter conditions in place. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 19:01:20 -07:00
jknapp	4df59da2d8	Merge pull request #22: Give the env var its value box back, and stop labelling the secret v0.4.4-mac v0.4.4-win v0.4.4	2026-08-11 22:34:30 +00:00
jknapp	a72406f0d8	Merge pull request #21: Bring the README back in step with the code, and give it a spine	2026-08-11 22:34:15 +00:00
shadow-testandClaude Opus 5	9b2f4fe79f	Give the env var its value box back, and stop labelling the secret ... Two separate faults, both reachable from one screenshot of the Global Environment Variables editor. The value input was collapsed to a sliver, so a variable looked like it had lost its value. `inputClass` carries `w-full`, and the `w-2/5` on the key input did not beat it — class-attribute order is not what resolves that conflict, stylesheet order is. The key therefore asked for the whole row, and the value input, whose `flex-1` gives it a basis of 0 and only the leftover space, got almost nothing. Widths now live on wrapper divs, where nothing competes with them. The fingerprint that detects custom-env changes was a plaintext `KEY=VALUE` join, and it is written as the `triple-c.custom-env-fingerprint` label. Labels are readable by anything on the host via `docker inspect`, `docker commit` copies them onto the project's snapshot image, and the recreation check logs both sides on a mismatch — so an API token set as a custom variable was published to all three. It is hashed now, exactly as `triple-c.git-token-hash` already was. Empty stays empty, so "nothing configured" still reads as an empty label. Changing the fingerprint format means every project's label mismatches once: expect a single container recreation per project on next start. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 15:27:19 -07:00
shadow-testandClaude Opus 5	e9ec2f8e26	Bring the README back in step with the code, and give it a spine ... Four feature commits landed after the last doc sweep without reaching the README, and cc5f691 documented only half of what it shipped. Adds the sections for browser view, corporate CA certificates, base-image migration and the LiteLLM model gateway, and refreshes the Key Files table, which was missing about ten modules. Fixes what had gone stale: the AWS directory mounts read-only at /tmp/.host-aws and is copied in by the entrypoint, not mounted at ~/.aws; Project Home has six tabs, not five; the Automation tab creates tasks as well as running them; Ctrl+Shift+left/right moves the active tab, and tabs can be dragged. Structurally, the sections are now grouped under Containers, Models and Authentication, Bridges to the Host, and Inside a Project, with a contents list and a table pointing at the other docs. Every section from before survives, in the same words where nothing changed — the file was 414 lines of internals with no way in and no map of where anything was. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 14:28:52 -07:00
jknapp	fa82d54afa	Merge pull request #20: New app icon: a mark that survives being 16 pixels tall v0.4.3-mac v0.4.3-win v0.4.3	2026-08-11 19:04:49 +00:00
shadow-testandClaude Opus 5	4c962ebd9c	Archive the marks the new icon replaces ... Neither is referenced by the app or the build; branding/archive/README.md says what each one was and why it did not survive the sizes an app icon is actually drawn at. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 12:03:28 -07:00
shadow-test	d15faa923b	Give the app a mark that survives being 16 pixels tall ... The icon is now a container with its right wall opened, so the enclosure itself is the letter C, holding a >_ prompt: the two things the app is, in one closed shape. It carries no type, so nothing goes illegible when the shell draws it small, and it uses the app's own accent tokens rather than a saturated orange field that fights the chrome behind it. icon.ico contained a single 16x16 image, which Windows was upscaling into the taskbar and every other slot — the likely cause of the artefact in screenshot_for_fix/. It now carries 16, 24, 32, 48, 64, 128 and 256, each rendered from vector rather than downsampled from one bitmap, and the entries at 32 and below come from a separate optical source: at that size the cursor bar closes up against the chevron, so the small variant drops it, widens the mouth and thickens the strokes. A test asserts the .ico keeps its small sizes so this cannot regress silently. Also adds the icon.icns that macOS bundles have been building without, points the favicon at our own mark instead of the missing /vite.svg, and puts the SVG sources, the lockups and the regeneration script in branding/. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 12:01:39 -07:00
jknapp	e379c58684	Merge pull request #19: Reorder tabs by dragging, and pop the browser view into its own window ... Tab reordering (drag, with a dragged copy under the cursor, or Ctrl+Shift+arrow) and the browser view in a window of its own, with Keep-on-top and match-window. Also, from using it: open a page in the container's browser at a chosen viewport, reachable from the Browser tab and the terminal's URL prompt; the Playwright split-tree bug that made every require("playwright") fail while the pane read green; the URL relay opening a different URL than the one on screen; preview builds that publish as prereleases, labelled with the version they preview, on the 0.4 line; and one CI run per push instead of two. v0.4.0-mac v0.4.0 v0.4.0-win	2026-08-11 18:20:15 +00:00
shadow-testandClaude Opus 5	ab747ce53d	Say what "open in container" is doing, and land on the pane doing it ... Opening a page is a container probe, a browser launch, a page load and often a viewer start — several seconds during which the only feedback was the click itself. Worse from a terminal, where the result appears in a pane the user is not looking at. So: the backend emits progress on the existing `container-progress` channel at each step, the Browser tab renders that line whenever it is set — the progress belongs to the project, not to whoever pressed the button, which is what lets a terminal-initiated open report anywhere at all — and the terminal's "In container" now selects the project's Browser tab before starting, so the line has somewhere to appear. Selecting a sub-tab from outside needed a route: `ProjectHome` keeps it in local state, so `openProjectHomeTab` parks a request in the store and the pane consumes it once. Consumed once, so it cannot fight the user's own clicking afterwards. Preview releases now prune themselves to the newest KEEP_PREVIEWS (2), in a job that runs only if all three platforms published — a half-finished run must not evict a good older build. The cleanup workflow's manual sweep stays as the backstop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 11:13:21 -07:00
shadow-testandClaude Opus 5	85ea3956e8	Stop the drag from selecting the tab's text ... A pointer-driven drag is still a mouse drag as far as the browser is concerned, so moving a tab highlighted its label blue — something the OS drag image never did, and the last visible difference between this and a real drag. `select-none` on the tab. The rename field gets `select-text` back: `user-select` inherits, and selecting text is exactly what that field is for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 11:00:06 -07:00
shadow-testandClaude Opus 5	5bd80a05bc	One build per push: previews carry the PR check ... Every push to the PR started two workflows on the same commit. build-app.yml ran on pull_request and compiled all three platforms — then published nothing, because every publishing step in it is gated on `gitea.event_name == 'push'`. build-app-preview.yml compiled the same three and published them. Six OS builds per push, half of them unreachable. So the PR trigger moves to the preview workflow, which was already doing the identical compilation and has something to show for it. build-app.yml is now push-to-main and manual dispatch only: releases. Two things a pull_request event changes, handled rather than inherited: `gitea.sha` can be the merge ref — not the commit anyone is testing, and not something to hang a tag on — so the release's target comes from `git rev-parse HEAD` in the checkout; and `gitea.ref_name` is the PR number, so the release body uses `gitea.head_ref` when there is one. The cost is one prerelease per PR commit touching app/**, which the existing Cleanup Old Releases sweep already prunes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 10:41:35 -07:00
shadow-testandClaude Opus 5	f239fa1c82	Fix three things found by actually using it ... **The drag showed no tab.** Moving to pointer events lost the drag image the OS used to supply, leaving a dimmed source tab and a 2px line — which reads as "some setting changed", not "I am holding this tab". A copy of the tab now follows the cursor, carrying its glyph and its real label, grabbed at the offset it was picked up by so it sits where the tab was. **The URL relay opened a different URL than the one on screen.** Observed: `repo.anhonesthost.net/…/tag/preview-63f3c54` arrived as `repo.anhonsthost.nt/…/preview-63f3c54Butitprovesyournitpick…`. The detector deleted *every* line break to undo PTY hard-wrapping, but a terminal that wraps at a space emits the break **instead of** the space — so deleting breaks also deletes the separators, gluing the following paragraph onto the link and running the match past the host. Only breaks the terminal inserted may be deleted, and those are exactly the ones at the column width. The detector now takes a live column getter and rejoins a line only when it is exactly that wide; every other break becomes a space, which is also what stops a URL match. Lines *longer* than the width are left alone — the stream had no break there, so the one that follows is the application's own. One case stays ambiguous: a URL whose length is an exact multiple of the width is indistinguishable from one that was cut. That is pinned in a test as known behaviour rather than papered over — the candidate is shown in full and nothing opens without the user pressing Open. **"In container" opened a page nobody could see.** It bound the browser and stopped, leaving the user to find the Browser tab and press Start, with nothing saying so — and from a terminal, no pane on screen at all. Opening a page now starts the viewer if it isn't running, and the terminal's prompt raises the pop-out window, because that caller has nowhere else to put it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 10:36:30 -07:00
shadow-testandClaude Opus 5	5b18ce804f	Start the 0.4 line, and give previews the version they are previewing ... Two version problems, one of them mine. **Previews claimed x.y.0.** The preview workflow hard-coded the patch number, so every preview installer reported 0.3.0 whatever it contained, while the real build computes the patch from tags. It now runs the same computation, so a preview is labelled with the version the release it previews would carry. **A new minor line started at the wrong number.** `compute-version`'s fallback for "no tag matches this line yet" counted every commit in the repository — fine as a bootstrap, wrong the moment a minor version is bumped: the first 0.4 build would have been 0.4.234. A line nobody has tagged is a new line, and a new line starts at .0. With those fixed, VERSION moves to 0.4 — tab reordering, the browser pop-out, opening pages in the container's browser and the Playwright install fix are more than a patch bump. The next release is v0.4.0; today's HEAD would have been 0.3.90 on the old line. `app/package.json`, `package-lock.json`, `tauri.conf.json` and `Cargo.toml` follow to 0.4.0. CI patches all four per build, so they are the dev-time defaults rather than the source of truth — but a local `tauri dev` shows them, so they should not still say 0.3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 10:06:00 -07:00
shadow-testandClaude Opus 5	63f3c54b95	Publish preview builds as a prerelease instead of workflow artifacts ... Workflow artifacts do not work on this Gitea, in two different ways: * upload-artifact@v4 cannot run at all. @actions/artifact v2's isGhes() treats any GITHUB_SERVER_URL that is not github.com / *.ghe.com / *.localhost as GitHub Enterprise Server and throws before making a single request. act_runner sets it to this instance, so all three platforms died with GHESNotSupportedError — after paying for the whole Tauri build (run #265). * @v3 uploads succeed and the files are downloadable by direct URL, but Gitea does not *list* them: /api/v1/…/runs/<id>/artifacts returns total_count 0 and the run page shows nothing (verified on run #267). A build nobody can find is not a build. So previews publish the way every other workflow here does: curl to the releases API. One prerelease per preview, tagged `preview-<sha>`, with all three platforms' bundles as assets — visible on the Releases page with stable links. The release is created in a job the three builds depend on rather than get-or-created in each. They run concurrently, so per-job creation races on one tag: the loser gets a 409, and the id parse then yields empty while the step still reports success — the failure build-app.yml's macOS job was hardened against after it happened for real. One creator removes the race instead of handling it. Asset upload keeps that hardening: delete-then-upload so a re-dispatch replaces rather than 409s, --http1.1 and retries for the mid-stream drops the macOS runner has produced (curl exit 92, exit 28), and an explicit failure when a platform produced no bundles at all. The `preview-` prefix is load-bearing: cleanup-releases.yml keeps recent `v<x>.<y>.<z>` releases and separately deletes every release whose tag does not start with `v[0-9]`, so previews are pruned by the cleanup already in use and never crowd the real release list. sync-release.yml is dispatch-only, so none of this reaches GitHub. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 09:38:06 -07:00
shadow-testandClaude Opus 5	f68d9c5788	Open a page in the container's browser, at a viewport you choose ... The pane could only ever watch a browser something else had published. This opens one: a URL and a viewport, launched inside the container and bound so the pane picks it up. Two uses, one action — a sign-in page, where the callback listener is *in* the container and the loop closes with no host round trip and no auth bridge, and a dev server on container loopback, which is how you watch a UI Claude is building. Reachable from both places the question comes up: "Open a page…" in the Browser tab, and an "In container" button on the terminal's URL prompt. Verified first, because it decided the design: a second client cannot join a bound browser. `chromium.connect()` against the published endpoint times out in every URL form (`ws+unix://…`, with and without the trailing path) — that socket speaks the dashboard's own transport, not the public connect protocol. Whoever launches is therefore the only process that can drive, so the helper is resident and holds the handle, and live resize applies to pages we opened and never to `@playwright/mcp`'s. Those take `--viewport-size` / `PLAYWRIGHT_MCP_VIEWPORT_SIZE` at launch, which the docs now say. The viewport is the interesting half. Resizing the *window* does nothing to the page — the viewer is a CDP screencast, so a bigger window is the same pixels drawn larger, which is why pages have been looking like they were rendered small. `page.setViewportSize()` genuinely reflows: measured against a `@media (max-width: 900px)` rule, it fires at 800×600 and clears at 1440×900. Match-window mode pushes the pop-out's settled size into it, debounced by generation counter because a drag emits `Resized` continuously and each one costs a container exec. Control is a polled JSON file in /tmp: no port, no second listener, nothing added to the proxy's surface, and URLs travel as argv to `node` so no shell ever parses one. A re-open with a helper already up navigates instead of relaunching — otherwise the second page would throw away the session the first one just signed into. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 09:15:12 -07:00
shadow-testandClaude Opus 5	bd72781482	Install one Playwright tree, and notice when a container has two ... Setup installed `playwright@latest` and `@playwright/cli@latest` together. Verified on a real container, that produces a tree that looks right and is broken: `@playwright/cli@0.1.18` pins `playwright-core@1.63.0-alpha`, npm hoists it, and `playwright@latest` (1.62.1) nests its own `playwright-core@1.62.1` beside it. The two cores want different browser revisions. The browser step runs the *resolved* — hoisted — CLI, so it downloads chromium-1237. Every script Claude writes says `require("playwright")`, gets the nested 1.62.1, and dies with: Executable doesn't exist at …/chromium_headless_shell-1234/… while the pane reports a browser installed, because one is. This is deterministic, not bad luck: every container set up through the pane lands in it. So the viewer package is installed first, and the `playwright` version installed after it is the one that package pins — read from the manifest npm just wrote, falling back to `@latest` only if it cannot be read. One core, one browser revision, both halves agreeing. Re-running "Set up Playwright" repairs an already-split tree. Detection now asks the question directly rather than listing a cache: it asks each resolved copy for `chromium.executablePath()` and whether that file exists — the viewer's copy *and* the one `require("playwright")` returns, since those are routinely different. `needs_browser()` covers "installed but not launchable", and the pane names both halves instead of saying "install a browser" over a cache that visibly has one. An absent field is "the probe didn't answer", never "skewed": containers predating these fields must not be told their browsers are wrong. The Rust side gets that from Option; the TypeScript mirror needed `!= null`, which an existing test caught. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 09:04:06 -07:00
shadow-testandClaude Opus 5	1207a21aae	Pin the preview build's uploads to upload-artifact@v3 ... Run #265 — this workflow's first ever run — built the app on all three platforms and then lost every bundle at the upload step: GHESNotSupportedError: @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES. v4 bundles @actions/artifact v2, whose isGhes() treats any GITHUB_SERVER_URL that is not github.com, *.ghe.com or *.localhost as GitHub Enterprise Server and throws before making a single request. act_runner sets that variable to this Gitea instance, so v4 cannot work here on any runner or any OS — and it fails *after* the whole Tauri build has been paid for. v3 uses the v1 artifact API, which Gitea implements. Both options this workflow relies on, `if-no-files-found: error` and `retention-days`, exist in v3. The other workflows never hit this because they publish by curling the Gitea releases API instead. Noted at the top of the file, with the isGhes rule, so the pin is not "upgraded" back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 08:00:06 -07:00
shadow-testandClaude Opus 5	a41d93ea46	Fix the review's findings: drag on pointer events, read the window back ... Ten findings from the review of the previous commit, all applied. **The tab drag is now pointer events, not HTML5 drag-and-drop.** Two independent reasons, either one fatal. Tauri's `dragDropEnabled` blocks HTML5 drag inside the webview on Windows, and it cannot just be turned off — `TerminalView` needs Tauri's native drag-drop event, which is the only one that carries dropped *file paths*. And an HTML5 drag carries a `DataTransfer`: released over any text field in the app, the default handler types `term:<uuid>` into it, and in Config that is then saved with the project. Pointer events have neither problem, and the drag is measured from the tabs on screen rather than from the event target, so the marker and the drop agree even over the marker itself. Escape abandons a drag; a press under 4px stays a click; the click that ends a drag does not select. **`Ctrl+Shift+←/→` no longer swallows word-wise selection.** It is bound on `document` in the capture phase, so in any input — the rename field, Config, Settings — it was taking the OS's extend-selection chord *and* silently reordering the strip. Guarded by `inTextField()`, which excludes xterm's helper textarea: that is an input-method shim, and the terminal is where the shortcut matters most. **The pop-out's state is read from the window, never remembered.** The pane is unmounted whenever another Project Home sub-tab is selected, so "Keep on top" came back Off over a window still floating on top. `get_browser_view_popout_state` returns both facts from the window itself, and the change event carries them. `poppedOut` is tri-state: until the answer arrives the iframe is not mounted, because guessing "not popped out" is what flashes a second viewer onto the browser. Also: `popout::close` and the off-status emit in the supervisor are behind the same epoch guard as the deregistration above them, so a supervisor whose teardown outlives a restart can no longer destroy the *new* session's window; `close()` returns its `destroy()` error instead of logging it and reporting success, since the pane restores its iframe on success; the drop marker is `pointer-events-none` and is placed before the first *visible* tab at or past the slot, so it neither refuses a drop nor vanishes when a `tabOrder` entry renders nothing; and the "Keep on top" Toggle's accessible name now matches its visible text. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 07:40:51 -07:00
shadow-testandClaude Opus 5	d73096c937	Reorder tabs by dragging, and pop the browser view into its own window ... Two things the UI couldn't do: rearrange the tab strip, and watch the browser while working somewhere else. **Drag to reorder.** `moveTab`/`moveActiveTab` on the store, HTML5 drag on the strip with a marker showing where the drop lands, `Ctrl+Shift+←/→` for the same thing without a mouse. Reordering deliberately does not select what it moves, so a drag aimed at a background tab doesn't yank the main area away from a terminal mid-run. A tab being renamed is not draggable — a draggable ancestor swallows the mouse-drag that selects text in its input. **Pop the browser view out.** `browser_view/popout.rs` opens the view's existing token-bearing loopback URL as a second OS window, with a "Keep on top" toggle so it can float above the app. Window-only: the viewer, the proxy and the container are untouched, so popping out and back interrupts nothing. Three things it rests on: - No capability lists that window, so it has no IPC surface — right for a page served out of a container, and it must stay that way. - The app CSP is irrelevant to it: `frame-src` constrains what the app's document may *embed*, and this is a top-level document. The port range and the token gate are what actually protect it, unchanged. - The window is owned by the session, so the supervisor's teardown closes it. A window onto a viewer that no longer exists is worse than none. The pane drops its iframe while popped out — two viewers can both *drive* the browser, and two cursors on one page is not a feature. `lib.rs`'s `on_window_event` is now guarded on `label() == "main"`. It fires for every window and its body stops every container and exits, so without the guard closing a pop-out would quit the app. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 06:50:40 -07:00
jknapp	57b6b71772	Merge pull request #18: Inject the corporate CA certificate into containers v0.3.84-mac v0.3.84-win v0.3.84	2026-08-10 18:48:53 +00:00
shadow-test	77567ac2ae	Merge remote-tracking branch 'origin/main' into feature/corporate-ca ... # Conflicts: # app/src/lib/tauri-commands.ts	2026-08-10 11:20:23 -07:00
jknapp	247f03b48c	Merge pull request #17: Browser view — find every Playwright, set one up in two clicks, bake the runtime libraries v0.3.78-mac v0.3.78-win v0.3.78 v0.3.81-mac v0.3.81-win v0.3.81	2026-08-10 18:19:25 +00:00
jknapp	31c73adb13	Merge pull request #16: Fix shared Claude auth — whole sign-in URL, recoverable rejected code	2026-08-10 17:58:57 +00:00
shadow-testandClaude Opus 5	4fdfed7955	Bake the browser's runtime libraries into the base image ... `npx playwright install chromium` downloaded ~150 MB of browser that then died with "error while loading shared libraries: libglib-2.0.so.0" — verified, not inferred, against the current image. The image shipped none of Chromium's shared libraries, which is why `apt install google-chrome-stable` looked like the cure: apt was quietly installing the same set as Chrome's own dependencies. Installing them at runtime instead converges on the worst possible state. The libraries land in the container's writable layer, so they are re-paid after every Reset and *lost* on base-image migration, which replays apt from a manifest. The browsers ride in ~/.cache/ms-playwright, inside the home volume, and survive both — leaving a 400 MB browser present with its libraries gone. So the libraries are baked and the browsers are not: each half now lives where it already persists. The layer runs `npx --yes playwright@latest install-deps chromium` rather than a hand-written apt list. Ubuntu 24.04's 64-bit-time_t transition renamed a swathe of these packages (libasound2t64, libatk1.0-0t64, libglib2.0-0t64, …) and a new Chromium dependency would drift straight back into the launch failure this exists to prevent; letting Playwright name its own dependencies is self-maintaining. It sits immediately after Node — npx is its only prerequisite — and well above the shim COPYs, so editing a shim does not re-run it. The `--dry-run` that follows is a build-time assertion, not decoration: on a platform Playwright has no list for, `install-deps` prints a warning and returns having installed **nothing, with exit status 0**. Without the assertion that ships a broken image behind a clean build log. Measured, on a build of this file with the layer applied over an otherwise identical image: +99 packages, +334 MiB unpacked and +119 MiB compressed (2950 → 3284 MiB, 759 → 878 MiB). Two thirds of that is not reachable by trimming — libgbm1, which Chromium needs, pulls mesa-libgallium, which pulls libllvm20. A chromium-only apt list measures 247 MiB against install-deps' 341 MiB; the ~94 MiB difference is xvfb and the CJK/emoji fonts, kept because the base ships no fonts at all and every page this feature exists to display would otherwise render as tofu. Verified on real builds, both architectures: a `--platform linux/arm64` build of this file installs the same 99 packages and passes the same assertion. On the new amd64 image, `playwright install chromium` with no `--with-deps` and no `install-deps` launches headless Chromium 151.0.7922.34 and loads a page; on the old image the identical script fails on libglib-2.0.so.0. `install.rs` no longer runs `install-deps` unconditionally — that would be a minutes-long apt run for nothing on a current image. It asks `install-deps --dry-run` first and skips the install when everything is present, saying which of the two happened on the progress stream. The check is Playwright's rather than a probe of our own for library names, so check and fix cannot disagree about what the dependency set is. Note that `--dry-run` exits 0 both when everything is installed and when Playwright has no list for the platform, so the verdict is read from its output. Containers on older images stay the normal case until people migrate, and they still work: on such an image the simulation cannot even resolve the package names (the index is cleaned in every base image), which reports as "couldn't tell" and installs — the right answer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k	2026-08-10 10:57:21 -07:00
Claude	7a5823cb2b	Inject the corporate CA certificate into containers ... Behind a TLS-terminating corporate proxy every HTTPS call inside a container fails — npm, pip, git, curl, the browser-view pane, and Claude Code's own API requests. There was no mechanism at all: installing the certificate by hand inside a container is lost on Reset and had to be repeated per project. A global CA path in AppSettings with a per-project override on Project, taking either a single certificate file or a directory. It is bind-mounted read-only at /tmp/.host-ca (mirroring /tmp/.host-ssh and /tmp/.host-aws) and applied by entrypoint.sh on every start, so it survives recreation, migration and Reset. Four things this gets right that are easy to get wrong: * update-ca-certificates globs *.crt case-sensitively, so a .pem that is merely copied in is ignored in silence. Certificates are renamed, by container_cert_name() in Rust and a mirrored few lines of shell. * The system store only serves curl/git/apt. Node — and so Claude Code itself — needs NODE_EXTRA_CA_CERTS, Python needs REQUESTS_CA_BUNDLE/SSL_CERT_FILE, and Chromium reads neither: it wants ~/.pki/nssdb, seeded with certutil (libnss3-tools, added to the image). * Those vars are set from Rust at creation, never exported by the entrypoint — a terminal is a docker exec and sees nothing the entrypoint exported. They are emitted empty when no CA is configured, since docker commit bakes env into the snapshot image. * triple-c.ca-fingerprint hashes the certificate bytes as well as the path, so a CA rotated in at the same location still forces a recreation. Verified end to end against a real container and a self-signed CA: curl, node, python and git all complete a TLS handshake against a server signed by it and all three fail in the same container without it; the env vars are visible from a docker exec session; the store is cleaned when the setting is cleared. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k	2026-08-10 10:40:21 -07:00
shadow-testandClaude Opus 5	a5bcc462a7	Browser view: find every Playwright, and set one up in two clicks ... Detection missed the npx cache, so a Playwright installed through Claude Code's MCP setup (`npx @playwright/mcp@latest`, which unpacks into ~/.npm/_npx/<hash>/node_modules and no node_modules at all) was invisible. The probe now globs that cache alongside the existing roots and reports every root it consulted. It also read `has_bind` off whichever manifest resolved first. Verified that npm does not hoist for global installs and that the `playwright` wrapper ships no types/types.d.ts, so `npm i -g playwright` made the pane call a current build "predates browser.bind()". The probe now hops from the wrapper to its nested playwright-core. The messages no longer offer `@playwright/mcp` as a way through setup: it bundles a playwright-core that binds but never `@playwright/cli`, so that route could not have worked. It is named only for what it does do. New `install.rs` + two commands do the setup, streaming on the existing `container-progress` event and re-probing on success: * playwright + @playwright/cli into /workspace as `claude`, --no-save. /workspace is not a bind mount (projects mount at /workspace/{mount_name}), so nothing of the user's is touched, no sudo is needed, and Node resolves it from scripts in the project. * A browser, as its own action with the size stated first: apt libraries as root, then the download, then a real headless launch to prove it works. The base image ships none of Chromium's shared libraries, which is why a download could succeed and the browser still not start. Chromium and the Chrome channel are both offered — @playwright/mcp asks for `chrome` specifically. A certificate failure is reported as a container trust-store problem rather than a broken install. Installing is always user-initiated; opening the tab only probes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k	2026-08-10 10:15:02 -07:00
shadow-testandClaude Opus 5	c3f92674b1	Fix the shared Claude auth flow: whole sign-in URL, recoverable rejected code ... Two compounding bugs made `claude setup-token` unusable, both measured against 2.1.226 under a pty rather than reasoned about. **The sign-in URL was truncated.** The CLI emits it as an OSC 8 hyperlink and slices the *visible* text of that hyperlink to the terminal width: a 346 character URL arrives at 80 columns as five separate hyperlink emissions, each carrying the whole URL in its parameter and 80 characters of it on screen. The transcript scraper picked up the first slice — a URL that parses, points at claude.com, and cannot authorise anything. The ANSI stripper now surfaces the OSC 8 target and `claude-token-link` carries it to the UI, which prefers it over the scraped text. It still goes through `sanitizeRelayUrl` with the ANTHROPIC_SIGN_IN_HOSTS allowlist before display and again before `openUrl` — an OSC 8 parameter is never rendered, which makes it the easier place to hide a hostile host, not a trusted one. The wrapped-display fallback is kept for CLI versions that print a bare URL. **A rejected code hung the flow.** On a bad paste the CLI prints `OAuth error: Invalid code…` / `Press Enter to retry.` and blocks on stdin instead of exiting; nothing recognised that, so the exec sat until the 15-minute timeout with the UI still saying "Finishing sign-in". Given the first bug handed the user a truncated URL, an invalid code was the likely first outcome. The streamed output is now scanned for that message, `claude-token-code-rejected` reopens the input with an explanation, and the Enter is sent so the next code has a prompt to land in — bounded by MAX_CODE_ATTEMPTS, after which the flow reports a failure. An undeterminable exec exit status is logged rather than silently read as success. **A wrapped token was rejected *and* leaked.** `stty cols` fails silently, and an 80-column fallback splits the ~103 character token across two lines: the parser saw a too-short fragment and failed, while the redactor masked the first line — which carries the `sk-ant-` marker — and printed the second, the tail of a live credential, to the UI in clear. `scan_credential_body` now reassembles a run across hard wraps and both the parser and the redactor use it, so they cannot disagree about where a credential ends. A join only happens across a break at a plausible terminal margin (>= 40 columns) and only for a run not already long enough to be a whole credential — without that second guard a repainting TUI welds one frame's token onto the next frame's first word. The length floor is applied to the reassembled body, so a fragment is still never accepted. Also: `stty cols` raised 200 -> 400 (the URL alone needs ~350), and `ESC ( B` is handled as the three-byte charset designation it is — it prefixes every repaint frame, and treating it as two bytes emitted a stray `B` that could glue itself onto a token and make the parser refuse it. `submit_claude_token_code`'s single-write behaviour is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k	2026-08-10 09:57:16 -07:00
jknapp	584fcdd837	Merge pull request #15: create the WOW64 junctions in the workflow instead of by hand ... Moves the last hand-made piece of the Windows fix into version control. Verified by deleting the manual junctions from the build VM first, so CI had to recreate them from scratch. v0.3.76-mac v0.3.76-win v0.3.76	2026-08-10 15:00:25 +00:00
shadow-testandClaude Opus 5	2c014fd752	CI: create the WOW64 junctions in the workflow instead of by hand ... The Windows fix was the only part of it living outside git — two junctions created by hand on the build VM. Rebuild that VM, add a second Windows runner, or reset the SYSTEM profile and Windows builds break again with an error that points nowhere near the cause. Tauri downloads candle.exe, light.exe and makensis.exe, and all three are 32-bit. A runner running as SYSTEM has %LOCALAPPDATA% under C:\Windows\System32\config\systemprofile, and WOW64 redirection serves 32-bit processes reading System32 from SysWOW64, where those directories do not exist. The bundlers cannot see their own folder: candle exits 0x80131700, makensis reports "Unable to start child process, error 0x2", and Tauri surfaces neither — only "failed to run candle.exe". The job now junctions the SysWOW64 view onto the System32 originals when it detects a profile inside System32, and skips entirely otherwise, so a runner running as a normal user is unaffected. Idempotent, and written with goto rather than nested blocks to avoid the delayed-expansion trap that already bit the MSVC step. Verified rather than assumed: the hand-made junctions were deleted from the build VM before this was pushed, so this run has to recreate them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-10 07:52:34 -07:00
jknapp	43e9959e40	Merge pull request 'Add llama.cpp + OpenAI backends, URL relay, browser view, and base-image migration' (#14) from feature/model-backends-and-browser into main	2026-08-10 06:23:43 +00:00
jknapp	e05156fd0e	Merge branch 'main' into feature/model-backends-and-browser	2026-08-10 06:13:40 +00:00
jknapp	aca6c49e3c	Merge pull request #13: Drop MCP management; add permission modes, Project Home, Auth Bridge and shared auth ... Claude Code absorbed MCP natively, so Triple-C stops managing it. Also adds permission modes, Project Home, Tier-1 accessibility fixes, the Auth Bridge, shared Claude authentication and the scheduler UI. 8 commits plus review fixes. 87 frontend tests, 34 Rust tests.	2026-08-10 05:43:09 +00:00
shadow-testandClaude Opus 5	0aa8315514	CI: restore the MSI now that the 32-bit bundlers can resolve their paths ... Dropping the MSI did not help: makensis.exe is 32-bit like candle.exe and failed the same way ("Unable to start child process, error 0x2"). The cause was WOW64 redirection sending 32-bit processes reading C:\Windows\System32 to SysWOW64, where the toolset directory does not exist. The build VM now carries junctions from the SysWOW64 view of systemprofile\AppData\Local\tauri and systemprofile\.cache to the System32 originals. Verified on the runner: candle.exe reports WiX 3.14.1.8722 and makensis reports v3.11, both exiting 0 from the path that previously failed. Both targets build again, so the .msi comes back. Artifact collection fails if either installer is missing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:34:59 -07:00
shadow-testandClaude Opus 5	29fd7de909	CI: restore the MSI now that the 32-bit bundlers can resolve their paths ... Dropping the MSI did not help, because the problem was never WiX. makensis.exe is 32-bit exactly like candle.exe and light.exe, lives in the same SYSTEM-profile cache, and failed the same way — "Unable to start child process, error 0x2" instead of 0x80131700. The cause is WOW64 redirection: a 32-bit process reading C:\Windows\System32 is served C:\Windows\SysWOW64, where the toolset directory does not exist, so the bundlers cannot see their own folder. The build VM now carries two junctions from the SysWOW64 view of systemprofile\AppData\Local\tauri and systemprofile\.cache to the System32 originals. Verified afterwards on the runner: candle.exe reports "WiX Toolset Compiler version 3.14.1.8722" and exits 0, and makensis reports v3.11 and exits 0 — both from the same path that failed before. So both targets build again and the .msi asset comes back. Artifact collection fails if either installer is missing rather than tolerating an empty directory. This is a host-side patch for a runner running as SYSTEM. A runner running as a normal user has a LOCALAPPDATA outside System32 and needs none of it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:34:43 -07:00
shadow-testandClaude Opus 5	fdc161fd9c	CI: build NSIS only on Windows, dropping the MSI target ... WiX's candle.exe/light.exe are 32-bit. On a SYSTEM-run runner Tauri caches WiX under C:\Windows\system32\config\systemprofile\..., and WOW64 redirection sends 32-bit processes to SysWOW64 where that directory does not exist, so candle exits 0x80131700. Tauri aborts the whole bundle on one target's failure, so the MSI was suppressing the NSIS installer too and Windows produced no artifact at all. NSIS is what the project already relies on for Windows upgrades. Drops the .NET 3.5 gate, which existed only for WiX; keeps the MSVC step, which is what makes the app link. Artifact collection now fails when no installer is produced rather than tolerating an empty directory. To restore the MSI, run the runner as a normal user and set --bundles msi,nsis. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:24:42 -07:00
shadow-testandClaude Opus 5	98a6c8fd56	CI: build NSIS only on Windows, dropping the MSI target ... The MSI target needs WiX, whose candle.exe and light.exe are 32-bit. On a runner running as SYSTEM, Tauri caches the WiX toolset under %LOCALAPPDATA% = C:\Windows\system32\config\systemprofile\..., and WOW64 redirection points 32-bit processes at SysWOW64, where that directory does not exist. candle.exe cannot see its own folder, the CLR fails to start, and it exits 0x80131700 — surfaced only as "failed to run candle.exe". Proven by running the identical toolset, as the same SYSTEM identity, from C:\wixtest (exit 0) versus the systemprofile path (0x80131700). Because Tauri aborts the entire bundle when one target fails, the MSI was also suppressing the NSIS installer — so Windows produced no artifact at all. NSIS is what the project already relies on for Windows upgrades, so dropping MSI costs the .msi asset and nothing else. Removes the .NET 3.5 gate, which only existed for WiX. The MSVC step stays: that is what makes the app link, and it works. Artifact collection now fails when no NSIS installer is present instead of tolerating an empty directory with 2>nul, so a silent packaging regression cannot pass as a green build again. To restore the MSI later, run the runner as a normal user — whose LOCALAPPDATA sits outside System32 — and set --bundles msi,nsis. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:24:29 -07:00