Compare commits

..
22 Commits
Author SHA1 Message Date
jknapp 81b1cfba09 Merge pull request 'Add a native Arch/CachyOS package via its own AUR publish workflow' (#39) from feat/arch-aur-package into main
Secret Scan / scan (push) Successful in 5s
2026-08-27 18:30:00 +00:00
jknapp ca6028bbb3 Merge pull request 'Work around WebKitGTK EGL crash on Wayland' (#38) from fix/wayland-webkit-egl-crash into main
Build App / compute-version (push) Successful in 3s
Secret Scan / scan (push) Successful in 3s
Build App / build-macos (push) Successful in 2m50s
Build App / build-windows (push) Successful in 4m46s
Build App / build-linux (push) Successful in 6m35s
Build App / create-tag (push) Successful in 3s
Build App / sync-to-github (push) Successful in 12s
2026-08-27 18:29:51 +00:00
shadow-testandClaude Sonnet 5 b3d07bda09 Fix real workflow bugs a review found: dead bind mount, blind error gate
Secret Scan / scan (push) Successful in 6s
Secret Scan / scan (pull_request) Successful in 6s
A review found the "Validate with makepkg and namcap" step's bind mount
(docker run -v "$PWD/rendered:/work") would very likely fail on Gitea's
own act_runner: a containerized job's $PWD isn't a path the daemon's host
can resolve, so the mount would silently attach an empty directory
instead of failing loudly — the same class of problem noted elsewhere for
this exact environment. Switched to docker create + docker cp (in and
back out) + docker start -a, the pattern already validated locally, which
works regardless of where the daemon actually lives.

Also found and fixed, most severe first:

- The namcap error gate (`grep -q "^[a-zA-Z0-9_-]*bin E:"`) only matched
  one of namcap's two line shapes for reporting an error
  ("triple-c-bin E: ...") and missed the other ("PKGBUILD
  (triple-c-bin) E: ...") entirely — confirmed by reproducing both against
  a real namcap run. The PKGBUILD-level half of the safety net was dead.
  Replaced with a plain `grep -q " E: "`, confirmed to match both real
  shapes (and a split-package variant) and nothing else.
- package()'s `ar x "Triple-C_${pkgver}_amd64.deb"` named the asset
  literally, defeating the whole point of the resolve step discovering
  the real filename from the release instead of assuming a pattern — a
  future Tauri bundler naming change would still break here with an
  opaque error. Changed to `ar x ./*_amd64.deb`, which `source=()` already
  guarantees matches exactly one file.
- `pacman -Sy` before installing packages is the canonical Arch partial-
  upgrade footgun; changed to `pacman -Syu --noconfirm --needed`.
- `${{ inputs.version }}` was interpolated directly into a shell step
  instead of routed through `env:`, unlike every other step in the file.
- `git push origin master` assumes the local branch name after cloning a
  brand-new (not-yet-created) AUR repo's empty state is `master`, which
  depends on the runner's own `init.defaultBranch` if the server sends no
  symref. `git push origin HEAD:master` is unambiguous either way.
- The private key was written with a plain redirect then chmod'd after,
  leaving a window where it's world-readable; now created at its final
  mode first via `install -m 600 /dev/null`. Added `-o IdentitiesOnly=yes`
  so a runner ssh-agent can't offer a different key first.
- Added GH_PAT auth to the api.github.com calls, matching every other
  workflow in this repo, to avoid the unauthenticated 60/hour rate limit.
- Fixed two comments: the `options` comment credited `!debug` for
  suppressing the empty debug-package directory, when it's actually
  `!strip` doing that (verified in a real build); and documented in the
  README that a hand-edit made directly in the AUR repo is silently
  reverted by the next dispatch, since every run renders fresh from this
  repo's template.

All of the above re-verified with the same real end-to-end methodology as
the original commit: real makepkg build, real namcap lint (clean), and
the exact updated docker create/cp/start sequence run against a live
container.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 11:24:31 -07:00
shadow-testandClaude Sonnet 5 e025a7441a Add a native Arch/CachyOS package via its own AUR publish workflow
Secret Scan / scan (push) Successful in 27s
Secret Scan / scan (pull_request) Successful in 10s
Part of triple-c#34's third ask ("I would like to also have an
Arch/CachyOS native version as well"), addressed separately from the
Wayland crash fix (fix/wayland-webkit-egl-crash) since it's an unrelated
feature, not a bug.

packaging/arch/PKGBUILD is a "-bin" AUR package repackaging the same .deb
build-app.yml already produces — no Rust/Node toolchain needed to install
it, and the user gets exactly the binary the project ships and tests.
Verified end to end against a real release (v0.4.14) rather than going by
Tauri's generic docs: downloaded the actual .deb, ldd'd the actual binary
to ground-truth `depends` (dropped `pango` and `libayatana-appindicator`
from an earlier draft — the first is already pulled in transitively by
gtk3, the second was never linked at all since this app has no tray icon
or menu), and ran a real makepkg/namcap/pacman -U cycle. namcap caught a
real issue this way (missing license file under
/usr/share/licenses/triple-c-bin/), now fixed by fetching LICENSE
alongside the .deb.

.gitea/workflows/publish-aur-package.yml does the actual publishing:
given a version (or "latest"), it finds that release's real Linux asset
on GitHub, downloads it, computes real checksums, renders the PKGBUILD
template, validates the result with makepkg and namcap inside a real
Arch container, and pushes to AUR. workflow_dispatch only, deliberately —
the same reasoning that killed sync-release.yml in triple-c#32 (releases
are assembled by build-app.yml across three separate platform jobs, so
there's no single automatic event that fires only once the Linux .deb
this needs actually exists) applies here too.

Requires a repo secret this workflow cannot set up itself:
AUR_SSH_PRIVATE_KEY, from an AUR account that has already created (or
been given co-maintainer access to) triple-c-bin — both one-time manual
steps on aur.archlinux.org. Until that secret exists, the workflow fails
loudly at the push step rather than silently doing nothing. See
packaging/arch/README.md for the full maintenance flow.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 11:10:55 -07:00
shadow-testandClaude Sonnet 5 8f62949902 Correct two overclaims in the Wayland workaround's comment
Secret Scan / scan (push) Successful in 4s
Build App (Preview) / compute-version (pull_request) Successful in 3s
Secret Scan / scan (pull_request) Successful in 4s
Build App (Preview) / create-release (pull_request) Successful in 2s
Build App (Preview) / build-macos (pull_request) Successful in 2m38s
Build App (Preview) / build-windows (pull_request) Successful in 4m48s
Build App (Preview) / build-linux (pull_request) Successful in 6m49s
Build App (Preview) / prune-previews (pull_request) Successful in 1s
Review found: "nothing this app's UI depends on" is backwards — the
terminal's @xterm/addon-webgl renderer is exactly the GPU compositing path
this setting disables, it just degrades gracefully (the addon's own
construction already handles WebGL being unavailable) rather than
crashing. And the "not simply Wayland vs X11" justification for going
unconditional doesn't hold up: WAYLAND_DISPLAY is exported into an
XWayland client's environment too, so gating on it would have caught that
case as well — the real reason to go unconditional is that there's no
reliable heuristic for the thing that actually matters (which
Mesa/driver/compositor combination is affected), not that the naive gate
misses XWayland specifically.

Also noted, not changed: the env var leaks to whatever the app spawns
afterwards (a cold-launched default browser via xdg-open), and the "=0
re-enables it" parenthetical isn't verified against WebKitGTK's own
source, so softened to say what's actually guaranteed (an already-set
value is left alone) rather than assume presence-vs-boolean parsing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 10:57:45 -07:00
shadow-testandClaude Sonnet 5 6354cb42b2 Work around WebKitGTK's EGL crash on Wayland (triple-c#34)
Secret Scan / scan (push) Successful in 5s
Build App (Preview) / compute-version (pull_request) Successful in 3s
Secret Scan / scan (pull_request) Successful in 3s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m39s
Build App (Preview) / build-windows (pull_request) Successful in 4m45s
Build App (Preview) / build-linux (pull_request) Successful in 5m10s
Build App (Preview) / prune-previews (pull_request) Successful in 3s
Reported on CachyOS/Arch with Wayland: the app aborts immediately with
"Could not create default EGL display: EGL_BAD_PARAMETER. Aborting."
printed straight to stderr by WebKitGTK's own C code, before Triple-C's
own logging even gets a chance to say anything useful about it.

This is WebKitGTK's DMA-BUF renderer (its default accelerated-compositing
path since 2.42) failing on some Mesa/driver/compositor combinations. Set
WEBKIT_DISABLE_DMABUF_RENDERER=1 unconditionally on Linux before the Tauri
builder runs, which is where GTK/WebKitGTK actually read it — there's no
reliable way to detect the affected combination ahead of time (reports of
this exact failure exist under XWayland too, not just pure Wayland
sessions), and WebKitGTK's fallback compositing path costs some rendering
performance this app's UI doesn't need. Left alone if a user has already
set the variable themselves.

Does not address the other two things filed under the same issue (links
not opening on the host, and a request for a native Arch/CachyOS package)
— those need more information / are a separate scope, respectively.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 10:45:24 -07:00
jknapp 9b55a12b32 Merge pull request 'Make preview versions monotonic and distinguishable from production' (#37) from fix/preview-version-numbering into main
Build App / compute-version (push) Successful in 4s
Secret Scan / scan (push) Successful in 3s
Build App / build-macos (push) Successful in 2m41s
Build App / build-windows (push) Successful in 4m50s
Build App / build-linux (push) Successful in 6m27s
Build App / create-tag (push) Successful in 3s
Build App / sync-to-github (push) Successful in 11s
2026-08-27 17:41:38 +00:00
shadow-testandClaude Sonnet 5 049232099b Dedupe the preview-build predicate, fix two comment inaccuracies
Secret Scan / scan (push) Successful in 24s
Build App (Preview) / compute-version (pull_request) Successful in 6s
Secret Scan / scan (pull_request) Successful in 6s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m39s
Build App (Preview) / build-windows (pull_request) Successful in 4m44s
Build App (Preview) / build-linux (pull_request) Successful in 6m17s
Build App (Preview) / prune-previews (pull_request) Successful in 1s
Final review pass gave this a clean bill of health overall but named
three small things:

- get_app_version() and check_for_updates() each read
  option_env!("TRIPLE_C_BUILD_SUFFIX") independently with slightly
  different idioms — if one were ever edited alone, the About panel and
  the update check could silently disagree about whether this is a
  preview build. Extracted preview_build_suffix() as the single place
  that reads and classifies it.
- pick_update's doc comment described the unparseable-tag case as a
  `-preview.<sha>` suffix; the actual tag build-app-preview.yml creates is
  `preview-<sha>` (no version, no dot) — already correct in the
  neighboring GitHubRelease::prerelease comment, just not here.
- That same prerelease comment claimed defence against a preview release
  leaking through backfill-releases.yml, but a preview's tag already fails
  semver parsing on its own — this field's actual job is the case parsing
  can't catch: a normally-tagged release someone flags prerelease on
  Gitea (a hotfix candidate, an RC) that a backfill would otherwise mirror
  as-is.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 10:34:56 -07:00
shadow-testandClaude Sonnet 5 945883bb9d Actually offer a preview the release it precedes, and fix two more gaps
Secret Scan / scan (push) Successful in 4s
Build App (Preview) / compute-version (pull_request) Successful in 3s
Secret Scan / scan (pull_request) Successful in 4s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m39s
Build App (Preview) / build-windows (pull_request) Successful in 4m50s
Build App (Preview) / build-linux (pull_request) Successful in 7m25s
Build App (Preview) / prune-previews (pull_request) Successful in 6s
An Opus review of the previous commit found its headline claim didn't
hold: a preview and the release it precedes compute to the identical
numeric version by construction, but check_for_updates compared with a
strict `>` against the bare CARGO_PKG_VERSION (never the suffixed display
string), so `(0,4,13) > (0,4,13)` is false and the release was never
offered. Plain semver ordering doesn't make a `-preview.<sha>` suffix sort
below the same numeric release on its own here, since the comparison
never sees the suffix at all.

pick_update now takes is_preview_build, derived from whether
TRIPLE_C_BUILD_SUFFIX was baked in, and relaxes that one comparison to
`>=` — so "a release exists at my own number" reads as an update. A
production build still requires strictly newer.

Also: ported build-app.yml's `git tag --points-at HEAD` guard into the
preview version computation. Without it, workflow_dispatch (which this
workflow allows on main, not just PR builds) run on a commit a release
was already cut from would compute one past that release — reintroducing
"preview outranks production" through the manual-dispatch door. And
corrected two comments that claimed the prerelease filter was currently a
no-op: backfill-releases.yml mirrors every Gitea release to GitHub
unfiltered, prerelease flag included, so it's real defence-in-depth
against a dispatched backfill leaking a preview release, not a no-op.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 10:24:24 -07:00
shadow-testandClaude Sonnet 5 b71e15c2c0 Make preview versions monotonic and distinguishable from production
Secret Scan / scan (push) Successful in 6s
Build App (Preview) / compute-version (pull_request) Successful in 3s
Secret Scan / scan (pull_request) Successful in 3s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m41s
Build App (Preview) / build-windows (pull_request) Successful in 4m51s
Build App (Preview) / build-linux (pull_request) Successful in 6m26s
Build App (Preview) / prune-previews (pull_request) Successful in 4s
build-app-preview.yml computed its patch number as
`git rev-list --count <latest tag>..HEAD` — the exact formula build-app.yml
itself documents as broken and replaced (#26): a distance from whichever
tag sorts highest, not a counter, so it resets to zero on every release and
previews went backwards (0.4.62 -> 0.4.0) the moment one landed. Ported the
same "one past the highest patch already used" computation build-app.yml
uses for real releases, reading the same tags (including -mac/-win
suffixes), so a preview built right before a release now computes the
exact number that release is about to take — semver already orders
`0.4.12-preview.<sha> < 0.4.12`, so a preview user is offered the release
the moment it ships instead of being silently pinned forever.

The installed preview's reported version was also indistinguishable from
production: the bundle's own version field strips the `-preview.<sha>`
suffix before touching tauri.conf.json/Cargo.toml/package.json, since the
Windows MSI's ProductVersion has no room for one. Rather than risk that
(unverifiable without an actual Windows build), preview builds now bake
the suffix into the binary separately via a TRIPLE_C_BUILD_SUFFIX
build-time env var, and get_app_version() appends it when present — a
production build sets nothing, so this is a no-op there.

Also: added `prerelease` to `GitHubRelease` and filter on it in
check_for_updates (currently a no-op against real data — nothing mirrored
to GitHub is ever prerelease:true — but the updater is no longer
structurally incapable of enforcing a channel split if one is ever made
explicit). And deleted sync-release.yml: workflow_dispatch-only, reading
gitea.event.release.* fields a manual dispatch never populates, so it
could never have actually run; build-app.yml's inline mirror already does
the same job.

Refactored check_for_updates' filtering into a pure, testable pick_update
helper (this file had no tests before), and added tests for it and the
new get_app_version suffix handling.

Fixes #32.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 10:11:35 -07:00
jknapp 06254db3d4 Merge pull request 'Report and retry Docker resources remove_project could not delete' (#36) from fix/remove-project-cleanup-reporting into main
Build App / compute-version (push) Successful in 5s
Secret Scan / scan (push) Successful in 4s
Build App / build-macos (push) Successful in 2m40s
Build App / build-windows (push) Successful in 4m54s
Build App / build-linux (push) Successful in 5m35s
Build App / create-tag (push) Successful in 13s
Build App / sync-to-github (push) Successful in 13s
2026-08-27 16:59:57 +00:00
shadow-testandClaude Sonnet 5 61bdbc4a5b Close the crash-window gap and exec-session leak a third review found
Secret Scan / scan (push) Successful in 16s
Build App (Preview) / compute-version (pull_request) Successful in 6s
Secret Scan / scan (pull_request) Successful in 6s
Build App (Preview) / create-release (pull_request) Successful in 3s
Build App (Preview) / build-macos (pull_request) Successful in 2m37s
Build App (Preview) / build-windows (pull_request) Successful in 4m52s
Build App (Preview) / build-linux (pull_request) Successful in 6m17s
Build App (Preview) / prune-previews (pull_request) Successful in 2s
A third Opus review pass confirmed round 2's fixes hold up, then found:

- The pending-cleanup record `remove_project` writes is fully durable
  (fsync'd); the projects_store.remove() that follows it is a plain
  fs::write with no fsync. A crash or power loss in that window — or that
  store write failing outright, beyond what the previous round's in-process
  rollback catches — leaves a record on disk naming a project
  projects.json still lists as present. The very next startup retry would
  then delete that project's container, snapshot image, and both volumes
  (including the one holding the OAuth credential and every session
  transcript) out from under a project the user still sees in the sidebar.
  retry_pending_cleanup_logged now takes the ProjectsStore and refuses to
  touch — clearing instead — any record whose project id still exists.
  Also stopped swallowing the round-2 rollback's own failure.
- Resolving the container through find_existing_container instead of
  project.container_id (round 2's stale-id fix) changed what drove
  close_sessions_for_container in remove_project and rebuild_project_
  container: sessions are now leaked when Docker is unreachable (nothing
  resolves, so nothing closes, and the project record is gone a moment
  later) and in the stale-id race itself (sessions were opened against the
  container that actually exists, not the id find_existing_container
  bypasses). Both functions now close sessions for the stored id
  unconditionally, and again for the resolved id if it differs.
- A pronoun-agreement bug in the no-retry removal toast ("remove them
  manually" for a single leftover) that was fixed one line above for verb
  agreement but not for the pronoun.

Also closed the test gaps the review named: the pending-cleanup
corrupt-record aside-move had no test, the Reset toast's leftover copy
was inline and untested (extracted to lib/resetOutcome.ts, mirroring
components/projects/home/removalReport.ts, with unit tests), and nothing
asserted rebuild()'s success path maps outcome.project into the list
rather than the whole outcome.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 09:47:45 -07:00
shadow-testandClaude Sonnet 5 439ef16f07 Fix two new bugs a second review found: stale container id, orphaned record
Secret Scan / scan (push) Successful in 5s
Build App (Preview) / compute-version (pull_request) Successful in 5s
Secret Scan / scan (pull_request) Successful in 4s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m40s
Build App (Preview) / build-windows (pull_request) Successful in 4m59s
Build App (Preview) / build-linux (pull_request) Successful in 6m28s
Build App (Preview) / prune-previews (pull_request) Successful in 1s
A second Opus review of commit 2 found it had introduced real problems of
its own rather than just polish gaps:

- remove_project's "None or stale" container-id fallback only handled
  None. A stale id (the documented start-failure race in
  start_project_container_locked, where the old container is removed and
  the new one's id isn't persisted until after start_container succeeds)
  still 404'd on removal — now treated as success by commit 1's own fix —
  while the real container survived to block every volume removal with a
  409 forever, with nothing in the pending-cleanup record ever naming it.
  Both remove_project and rebuild_project_container now resolve the
  container via find_existing_container() unconditionally, matching every
  other container-destroying path in the codebase, and remove_project
  fails closed (records a leftover rather than silently skipping) if
  Docker itself can't be reached to check.
- remove_project could leave a pending-cleanup record for a project still
  live in projects.json: if the store's own save failed after the record
  was written, startup housekeeping would delete that project's container
  and volumes out from under it on the next launch. The record is now
  rolled back when the store write fails.
- rebuild_project_container (Reset) only surfaced a leftover volume, not a
  leftover snapshot image — the more serious failure, since the next
  container is built from that image whenever it exists, silently
  reviving the exact system layer Reset was asked to discard.
  ProjectResetOutcome now carries leftover_image too, and the toast's
  "run docker volume rm" advice is corrected: the new container has
  already remounted the volume by the time the toast renders, so that
  command would just hit the same conflict Reset did.

Also from the same pass: reworded a couple of log/toast lines that still
asserted resources were "still present" when the daemon-unreachable case
covered by the same code path can't actually confirm that; fixed a
singular/verb mismatch in the leftover toast text; moved an unparseable
pending-cleanup record aside instead of re-warning about it forever; and
added a debug log when a record's recorded_at can't be parsed, so aging
never silently no-ops.

Pulled describeLeftovers/leftoverVerb out of ProjectHome.tsx into their
own module with unit tests, and added tests for the recorded_at staleness
check — the previous commit's equivalent logic had none.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 09:09:46 -07:00
shadow-testandClaude Sonnet 5 d8bb5ab262 Address review findings: durability, stale container ids, honest toasts
Secret Scan / scan (push) Successful in 4s
Build App (Preview) / compute-version (pull_request) Successful in 3s
Secret Scan / scan (pull_request) Successful in 6s
Build App (Preview) / create-release (pull_request) Successful in 2s
Build App (Preview) / build-macos (pull_request) Successful in 2m38s
Build App (Preview) / build-windows (pull_request) Successful in 6m18s
Build App (Preview) / build-linux (pull_request) Successful in 7m48s
Build App (Preview) / prune-previews (pull_request) Successful in 1s
An Opus review of the previous commit found several real gaps:

- pending_cleanup::save used plain write-temp-then-rename, unlike
  migration_store's fsync'd write it claimed to mirror — a crash in that
  window left a truncated record that list() would skip forever, silently
  reproducing the exact bug this module exists to fix. Now matches
  migration_store's File::create/write_all/sync_all/rename/sync_dir shape,
  and the tests exercise the real save/list/clear functions against a temp
  dir instead of re-implementing their bodies inline.
- remove_project and rebuild_project_container only ever looked at
  project.container_id, unlike every other container-destroying path in the
  codebase, which falls back to find_existing_container for exactly this
  race (a crash between creating a container and persisting its id). A miss
  here left a container that then blocked every subsequent volume removal
  with a 409, forever. Both now resolve the same way the rest of the
  codebase does, and record the container by its deterministic name rather
  than its id so a retry still has something that resolves.
- remove_project's toast promised an automatic retry unconditionally, even
  when writing the pending-cleanup record itself failed (the one case
  where nothing will actually retry). ProjectRemovalReport now carries
  retry_scheduled, and the UI is honest about which case it's in.
- remove_volumes_by_name now retries once after a short delay on a 409,
  since Docker releasing a volume's mount reference right after its
  container is removed is not always instantaneous, and this is exactly
  the sequence remove_project runs.
- rebuild_project_container (Reset) returns ProjectResetOutcome so the UI
  can warn when Reset could not fully clear a project's volumes, instead
  of only logging it — the new container silently reuses old data
  otherwise, which is what Reset promises not to do.
- retry_pending_cleanup_logged escalates a record's log level after it has
  failed for a week, since recorded_at was otherwise write-only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 08:36:27 -07:00
shadow-testandClaude Sonnet 5 4827170715 Report and retry Docker resources remove_project could not delete
Secret Scan / scan (push) Successful in 10s
Build App (Preview) / compute-version (pull_request) Successful in 7s
Secret Scan / scan (pull_request) Successful in 8s
Build App (Preview) / create-release (pull_request) Successful in 5s
Build App (Preview) / build-linux (pull_request) Successful in 6m5s
Build App (Preview) / build-macos (pull_request) Successful in 2m45s
Build App (Preview) / build-windows (pull_request) Successful in 5m42s
Build App (Preview) / prune-previews (pull_request) Successful in 3s
remove_project_volumes always returned Ok(()) regardless of what actually
happened, making the `if let Err(e)` guarding it at every call site dead
code. remove_project then dropped the project record unconditionally, so a
volume, image or container that failed to delete became permanently
unreachable — confirmed against a real orphaned volume pair found in the
wild (fixes #31).

remove_project_volumes/remove_snapshot_image/remove_container now report
what they could not remove (treating "already gone" as success rather than
a leftover), remove_project surfaces this to the user via a toast, and
before dropping the project record it writes a pending-cleanup record that
startup housekeeping retries automatically on the next launch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
2026-08-27 08:18:41 -07:00
jknapp 1a79852f65 Merge pull request 'Remove a live credential from a test fixture, and scan for the next one' (#33) from fix/test-fixture-secret into main
Build App / compute-version (push) Successful in 3s
Secret Scan / scan (push) Successful in 4s
Build App / build-macos (push) Successful in 2m36s
Build App / build-windows (push) Successful in 4m50s
Build App / build-linux (push) Successful in 6m46s
Build App / create-tag (push) Successful in 4s
Build App / sync-to-github (push) Successful in 11s
Reviewed-on: #33
2026-08-25 18:54:56 +00:00
shadow-testandClaude Opus 5 68b73a9102 Refuse a commit that adds something shaped like a credential
Secret Scan / scan (push) Successful in 4s
Build App (Preview) / compute-version (pull_request) Successful in 4s
Secret Scan / scan (pull_request) Successful in 5s
Build App (Preview) / create-release (pull_request) Successful in 2s
Build App (Preview) / build-macos (pull_request) Successful in 2m34s
Build App (Preview) / prune-previews (pull_request) Canceled after 0s
Build App (Preview) / build-linux (pull_request) Canceled after 3m23s
Build App (Preview) / build-windows (pull_request) Canceled after 3m26s
The companion to the fixture removal. A site-admin token sat in a test file for
92 commits and fourteen days on a public mirror, past five audit rounds and two
independent reviews, because all of them read the code under change and this was
not under change. A grep would have caught it the first day.

`scripts/scan-secrets.sh` is that grep, in three rules:

  * vendor-prefixed credentials — `ghp_`, `github_pat_`, `glpat-`, `xox*-`,
    `sk-`, `AKIA`/`ASIA`, `ya29.`, `AIza`, `npm_`, `dckr_pat_`. Shape alone
    identifies these, so there is no context to get wrong.
  * `BEGIN … PRIVATE KEY` blocks.
  * an opaque literal assigned to a secret-shaped name — the rule that would
    have caught this one.

The third rule needs **both** halves, and that is what makes it usable rather
than another disabled check. Measured before writing it: an entropy-only rule
flags 317 literals in this tree, and name-proximity alone flags four, three of
which are `secure::get_project_secret(&id, "aws-secret-access-key")` — a
keychain *key name* sitting next to the word `secret`. Requiring the literal
itself to be hex or base64 with no word structure is what excludes those.

Validated rather than asserted:

  * **0 false positives** across every tracked file.
  * **Catches the real incident** — `--range 9b2f4fe~1..9b2f4fe` is refused.
  * Twelve shaped cases pass and fail as intended, including a sha256 in an
    `assert_eq!`, a git sha in a comment and the new dummy fixture, none of
    which trip it.
  * The hook was proved to block an actual `git commit`, not just to exist.

Two halves, because each covers the other's gap:

  * `.githooks/pre-commit`, enabled per clone by `npm run hooks`. Git will not
    let a repository set its own hooks path — cloning would then be enough to
    run its code — so this is opt-in everywhere and `--no-verify` skips it.
  * `Secret Scan`, which nobody can bypass. It carries **no `paths:` filter** on
    purpose: the leak lived in `app/**` and `build.yml` only runs for
    `container/**`, so a path-filtered scan would have missed the very thing it
    exists for. It scans the whole tracked tree rather than a range, because a
    wrong range fails *open* and the full pass takes 0.5s.

Also fixed while here: `core.hooksPath` in this clone pointed at
`/workspace/.git/hooks`, a directory that does not exist — so git hooks were
disabled outright and anything dropped in `.git/hooks` would have been ignored
in silence. A hook that never runs is worse than no hook, because the checklist
says it is there.

`--tracked` skips binaries. Feeding a blob to grep gets "binary file matches"
instead of the line, so a genuine finding inside one would arrive as a sentence
nobody can act on.

A line ending `pragma: allowlist secret` is skipped — wordy on purpose, so it
reads as a claim and leaves something greppable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LHL9ty7arp8FHwvE77ne7y
2026-08-25 11:51:04 -07:00
shadow-testandClaude Opus 5 d09e2a2743 Stop using a live credential as a test fixture
`the_custom_env_fingerprint_never_carries_the_value` asserted that the custom-env
fingerprint does not leak a secret — using the maintainer's real Gitea token as
the secret. It was committed on 2026-08-11 in 9b2f4fe, reached 92 commits, and
was readable for fourteen days in the public GitHub mirror at
`shadowdao/triple-c`, confirmed by fetching the raw file.

The token was a **site-admin** token (`is_admin: true`, user id 1) with admin
rights on every repository the account can see, not a repo-scoped one. It has
been revoked; the API now answers 401.

Release bundles were never affected — the literal is inside `#[cfg(test)]`, and
a search of the shipped 0.4.62 AppImage finds nothing.

The fixture is now an obviously fake string, and the test is unchanged
otherwise. Mutation-checked against the replacement: a fingerprint that returns
the raw value, one that returns the key name, and one that ignores its input are
all still caught, so nothing about the test's power depended on the value being
real — which was true the whole time.

History is deliberately **not** rewritten. The value was public for two weeks, so
rotation is the fix and the old value is now worthless; rewriting 92 commits of
published history would break every clone to hide something already seen.

Worth noting how this survived: five audit rounds and two independent reviews
all pointed at new code, and this sat in a test file that none of them had reason
to open. A high-entropy-literal check in CI would have caught it on the day.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LHL9ty7arp8FHwvE77ne7y
2026-08-25 11:29:16 -07:00
jknapp 4371c9f03e Merge pull request 'Terminal newlines, OAuth callback, Claude Code settings, and the Files tab' (#30) from ship/core into main
Build App / compute-version (push) Successful in 5s
Build Container / build-container (push) Successful in 2m30s
Build App / build-macos (push) Successful in 2m37s
Build App / build-windows (push) Successful in 5m28s
Build App / build-linux (push) Successful in 7m49s
Build App / create-tag (push) Successful in 23s
Build App / sync-to-github (push) Successful in 11s
Five audit rounds of terminal, auth, settings and Files-tab work, plus the Files tab regaining its host transfers in a shape that opens the OS dialogs from Rust.

480 Rust tests, 602 frontend, no new clippy warnings.
2026-08-25 18:02:58 +00:00
shadow-testandClaude Opus 5 eead748222 Close what two reviews found in the Files tab transfers
Build App (Preview) / compute-version (pull_request) Successful in 5s
Build Container / build-container (pull_request) Successful in 37s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m40s
Build App (Preview) / build-windows (pull_request) Successful in 4m56s
Build App (Preview) / build-linux (pull_request) Successful in 5m11s
Build App (Preview) / prune-previews (pull_request) Successful in 1s
Two independent reviews of 2c9482a, one for correctness and one against the
threat model. Between them they found two ways to lose a file, one way for a
container to choose a Windows save destination, and a rule that made every
dotfile unsavable. Every finding below was demonstrated against a real
container before being fixed, and the fixes are demonstrated the same way.

## The download was accepting truncated reads and refusing whole ones

The `[ -f ]` bracket around the read was wrong in both directions.

It missed the case that loses data. Truncation *in place* — `> file`, log
rotation, `tar -x`, most build tools — leaves a regular file behind, so `dd`
stopped at the new EOF and exited 0. Measured: a 600 MB source truncated
mid-read delivered 34 MB, which was then renamed over the user's own earlier
copy and toasted as `Saved (34.1 MB)`. Truncate-to-zero did the same and needs
no adversary at all.

And it failed *good* downloads. `dd` already holds the fd, and neither `rm` nor
`mv` can touch an open one — the bytes are complete. But `rm` makes `[ -f ]`
false, so a finished 600 MB transfer of a file a bundler happened to unlink was
deleted, reporting "nothing was saved". The comment claiming the bracket caught
a "mix of two files" was simply wrong; an open fd cannot be a mix.

So the script now measures the file before reading it and puts the answer on
stderr, and Rust checks that at least that many bytes arrived. One rule,
subsuming everything the bracket was for. Verified against a real container:
truncation mid-read and the FIFO race are refused; deletion, rename-over, a
growing file, an empty file and an untouched 600 MB read all pass.

## On Windows the container, not the user, was naming the save destination

`suggested_save_name` split on `/` only, and it feeds the save dialog's
pre-filled name. Backslash is a legal Linux filename character and
`validate_container_path` has no reason to object — `..\..\Users\…` is one
POSIX segment. The Windows common file dialog parses its name box as a path on
Save, so a container-created file called
`..\..\..\Users\vic\AppData\Roaming\Microsoft\Word\STARTUP\x.dotm` put its own
bytes in an auto-loading Office directory on one un-read click. `resolve_host_path`
did not stop it: Word's `STARTUP` and Excel's `XLSTART` are not in the autorun
denylist, which this file's own docs already concede is "losing by
construction" and was never meant to be the boundary here.

The name is now sanitized of every separator, the drive colon and the rest of
what NTFS refuses, so it cannot be a path on any platform this ships to.

## No dotfile could be saved, and the app pre-filled the name that guaranteed it

The write policy judged the leaf for hiddenness, so `/workspace/.env` was
refused *after* the modal and the overwrite prompt — quoting the name the app
itself had suggested. `.gitignore`, `.dockerignore`, `.eslintrc.json`, `.nvmrc`:
all unsavable, while uploading them worked, so a dotfile could go in and never
come out.

`HostPathUse` gains a third mode. `WriteChosenName` drops the leaf check and
keeps every directory rule, and only `download_container_file` uses it — the
dialog is a real boundary for that caller and only that caller.
`download_container_backup` still takes its path over IPC as a string and keeps
the strict rule.

## Smaller, all found by the reviews

  * A download had no ceiling. `dd` resolves through the container's `PATH`,
    which its agent owns with passwordless sudo; a replacement writing forever
    was measured at ~6 GB/s, so one click on a file listed as 2 KB filled the
    host disk with no progress shown and no cancel. Bounded now by what the
    file measured, with slack that is absolute for small files and
    proportional for large ones, so an honest growing log is unaffected.
  * "Framed rather than verbatim" did not stop container text reaching the
    toast headline: `readableRefusal` matches with `includes`, and it has to,
    because the app's own refusals carry those markers mid-sentence. Anchoring
    would break them. The fix is at the injection point — container text is
    clipped to one 200-character line with control characters stripped — plus a
    `max-h-40` on the toast message, which the `detail` block always had and
    this half did not. 8 KB of prose in a `z-[60]` card pushed its own dismiss
    button off-screen.
  * `savingPath` was a scalar while the design deliberately allows concurrent
    saves. Starting a second freed the first's row mid-transfer, and whichever
    finished first cleared both; dismissing the second dialog was enough. It is
    a `Set` now.
  * `setUploading(false)` fired when the command settled, not when the refresh
    finished, so a second click landed mid-relisting.
  * `upload_files_to_container` checked the container directory before the
    picker and then used the unresolved path. A modal has no time limit. It
    re-checks after, which is what `docker::exec`'s doc comment already claimed.
  * `wait_for_exec_exit` flattened a missing exit code to `Some(0)`, which made
    the new `!= Some(0)` check unreachable by construction.
  * `normalize_host_path` did not collapse repeated separators, so the lexical
    system-root rule was silently absent for `C:\\Windows\…`. Not exploitable —
    the resolved pass catches it — but a documented layer that does nothing is
    a trap for the next caller.
  * README still carried the "no host path crosses IPC in either direction"
    claim the previous commit narrowed everywhere else, and HOW-TO-USE
    described the hidden rule without saying it applies to folders only.

480 Rust tests, 602 frontend, no new clippy warnings. Eleven mutations against
the new tests, all killed — two of the first round survived and were rewritten:
one because `split_whitespace` already handled the case I thought I was
testing, one because I had deleted a comment rather than the behaviour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LHL9ty7arp8FHwvE77ne7y
2026-08-25 10:42:26 -07:00
shadow-testandClaude Opus 5 2c9482a67d Give the Files tab back its uploads and downloads
Build App (Preview) / compute-version (pull_request) Successful in 4s
Build Container / build-container (pull_request) Successful in 1m35s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m38s
Build App (Preview) / build-windows (pull_request) Successful in 5m51s
Build App (Preview) / build-linux (pull_request) Successful in 6m50s
Build App (Preview) / prune-previews (pull_request) Successful in 1s
`upload_file_to_container` and `download_container_file` existed on main before
any of this work started. "Ship the Files tab container-side only" removed them
and called it narrowing scope; from a user's side it was a regression they
upgraded into. This restores the feature.

The reason for the removal was real — four consecutive audits found their
criticals in host paths crossing IPC — so the feature comes back only in the
shape that removes the class rather than patching it a fifth time. The dialogs
are opened by **Rust** (`pick_save_path`, `pick_files_to_upload`), not by the
webview. A frontend `open()`/`save()` handing the backend a path string is
exactly what failed, and the backend cannot tell such a string from one a
compromised webview invented. Now the webview can ask for a picker and that is
the whole of its influence: it cannot name a host path as an input. That is the
shape the previous round's own notes named as the honest one if this ever
returned.

None of the machinery the audits condemned returns. No `link(2)` destination
reservation, no placeholder rollback, no collision marker: the OS save dialog
already asks about overwriting and Docker's extractor overwrites on upload the
way `cp` does, so there was nothing left for it to do. Download reuses the
sequence `download_container_backup` has been using unchanged — resolve, stream
into a partial file beside the destination, rename last — so a failed transfer
never touches the file that was already there. Upload reuses the terminal
drop's hardened uploader, with the container's uid/gid resolved once per
selection rather than once per file.

Against a container that is actively hostile rather than merely surprising:

  * the read is `dd iflag=nonblock`, not `cat`. `[ -f ]` and the `open` after it
    are two syscalls and the container owns the filesystem in between; a loop
    swapping the file for a FIFO wins that race, and `cat` then blocks forever
    with no writer and no timeout anywhere on the path — the `invoke` never
    settles and a partial is left in the user's directory for good. Verified in
    a real container that `cat` hangs, that `iflag=nonblock` returns, and that
    it is byte-identical on a regular file.
  * the read is bracketed by a second `[ -f ]`, because non-blocking turns that
    hang into an empty file that would otherwise be renamed over the
    destination and reported as a successful save.
  * an *undeterminable* exit code is a failure. Backup catches this class with
    its `total == 0` check, which download cannot have because an empty file is
    a legitimate save; without a replacement, a project restarted mid-download
    renames a truncated partial over the user's file and reports the byte count
    as if it were whole.
  * container stderr is capped. Every other reader of container output in the
    tree is capped for this reason; the two streaming commands were the
    exception, and stdout was bounded by disk while stderr was bounded by
    nothing.
  * the script's refusals are framed rather than used verbatim, so a directory
    named to look like one of our own sentences cannot become the toast
    headline through `readableRefusal`.
  * the partial name is capped at NAME_MAX. A bundler's 230-character content
    hash is a name that fits its directory and produces a partial name that
    does not.

Also: a non-UTF-8 dialog path is refused by name rather than silently mangled
into a different path by U+FFFD substitution; both actions carry in-flight
state, so a second click cannot open a second dialog and a slow save is not
indistinguishable from a dead button; and the upload's completion message names
the directory, since the picker is modal and the user can browse elsewhere
while it is open.

Not restored: drag-and-drop, in either direction. `drag:allow-start-drag` stays
ungranted and `hold/disk-and-dragout` still holds that work.

Two bugs the new tests caught while being written: a double-click on "Save to
host…" opened the file viewer on top of the save dialog, and an N-file upload
made N redundant execs to re-ask `id -u`.

Docs that asserted this feature did not and must not exist are corrected —
CLAUDE.md, README, HOW-TO-USE, TECHNICAL and the capability threat model. The
"no host path crosses IPC" claim is deliberately narrowed to the inbound
direction: paths do still travel outward inside error text, canonical ones
included, and the reviewed record should not overstate.

600 frontend tests, 473 Rust, no new clippy warnings. Every new test was
mutation-checked; four that survived their first mutation were rewritten,
including two whose mutations turned out to be unfaithful and one that was
blind to a dismissal leaving a row stuck on "Saving…".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LHL9ty7arp8FHwvE77ne7y
2026-08-25 10:00:21 -07:00
shadow-testandClaude Opus 5 88ffb4744a Cancel the keydown on Shift+Enter, or xterm submits anyway
Build App (Preview) / compute-version (pull_request) Successful in 4s
Build Container / build-container (pull_request) Successful in 36s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m56s
Build App (Preview) / build-linux (pull_request) Successful in 5m8s
Build App (Preview) / build-windows (pull_request) Successful in 5m38s
Build App (Preview) / prune-previews (pull_request) Successful in 1s
The handler returned `false` from xterm's custom key handler and a
comment claimed that was enough to stop the bare CR. It is not.
`_keyDown` returns the instant the handler says `false` — before it sets
`_keyDownHandled` and before it cancels the event — and `_keyPress` then
checks that same flag, finds it false, and emits a bare CR for Enter's
charCode 13.

So the headline feature of this branch did the wrong thing in a real
browser: Shift+Enter inserted the newline and then submitted the
half-written prompt, now with a stray blank line in it. Arguably worse
than before the fix. Reproduced in Chromium and confirmed against the
bundled xterm 5.5.0 source.

`preventDefault()` is what stops the browser firing keypress at all.
Applied at both call sites — the desktop terminal and the web terminal's
copy.

The test could not have caught this. jsdom never synthesizes the
follow-up keypress, so `expect(sent()).not.toContain("\r")` was asserting
a property the environment cannot falsify — a test named for a behaviour
it could not exercise. It now asserts `defaultPrevented`, which is the
mechanism that actually suppresses the keypress and which jsdom can
observe. Mutation-checked: removing the `preventDefault()` fails it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc
2026-08-23 20:47:01 -07:00
47 changed files with 4166 additions and 292 deletions
+83 -10
View File
@@ -43,7 +43,18 @@ name: Build App (Preview)
# prunes previous previews itself, keeping the newest few. Bundles are ~130 MB a
# release; the point of a preview is the build you are testing now.
#
# `sync-release.yml` is workflow_dispatch-only, so nothing here reaches GitHub.
# A preview release is not meant to reach GitHub. `build-app.yml`'s inline
# mirror never sees one (it only runs for its own `push`-triggered release),
# but `backfill-releases.yml` pulls every Gitea release unfiltered and would
# faithfully forward a preview's `prerelease: true` if it were ever dispatched
# while one existed — so `GitHubRelease::prerelease` in `update_commands.rs`
# is real defence, not a no-op, even though the `preview-<sha>` tag shape
# (never valid semver) already blocks it independently. (The previous
# mechanism here, `sync-release.yml`, was `workflow_dispatch`-only and read
# `gitea.event.release.*` fields that are only ever populated by a `release`
# trigger, so it could never have actually run; deleted rather than fixed,
# since build-app.yml's inline mirror already does what it was meant to do
# for real releases. See triple-c#32.)
env:
GITEA_URL: ${{ gitea.server_url }}
@@ -70,12 +81,23 @@ jobs:
outputs:
version: ${{ steps.version.outputs.VERSION }}
sha: ${{ steps.version.outputs.SHA }}
# Everything after the first `-` in VERSION (e.g. `preview.a1b2c3d`).
# The bundle version fields never see this — see "Set app version" in
# each build job — but it is baked into the binary as
# `TRIPLE_C_BUILD_SUFFIX` so `get_app_version()` can still report it.
# An installed preview otherwise reports the same bare number a
# production build would, indistinguishable in the About panel and to
# `check_for_updates`. See triple-c#32.
suffix: ${{ steps.version.outputs.SUFFIX }}
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Fetch all tags
run: git fetch --tags
- name: Compute preview version
id: version
run: |
@@ -86,21 +108,60 @@ jobs:
# is testing and not something to hang a tag on.
echo "SHA=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT
# The patch number is computed exactly as build-app.yml does it, so a
# preview is labelled with the version the release it previews would
# carry. This used to be hard-coded `.0`, which made every preview
# installer claim to be x.y.0 no matter what it contained.
LATEST_TAG=$(git tag -l "v${MAJOR_MINOR}.*" --sort=-v:refname | grep -E "^v${MAJOR_MINOR}\.[0-9]+$" | head -1 || true)
if [ -n "$LATEST_TAG" ]; then
PATCH=$(git rev-list --count "${LATEST_TAG}..HEAD")
echo "Latest matching tag: ${LATEST_TAG} (+${PATCH} commits)"
# The patch number must be the same "one past the highest patch
# already used" build-app.yml computes for a real release — not a
# distance from the latest tag. It used to be
# `git rev-list --count <latest tag>..HEAD`, which build-app.yml's
# own history section documents as broken for exactly this reason:
# it resets to zero on every tag cut, so previews went *backwards*
# (0.4.62 -> 0.4.0) the moment a release landed, and nothing stopped
# a preview number from later colliding with a real release's.
#
# Reading the same `v${MAJOR_MINOR}.*` tags (including the `-mac`
# / `-win` suffixed ones a partially-published release can leave
# behind) means a preview built right before a release computes the
# exact number that release is about to take — e.g. `0.4.13` for
# both. That makes the two numerically *equal*, not "preview less
# than release" — plain semver ordering does not make a
# `-preview.<sha>` suffix sort lower on its own here, because
# `check_for_updates` compares against the bare, stripped
# `CARGO_PKG_VERSION`, never the suffixed display string. What
# closes the loop is `update_commands.rs`'s `is_preview_build`
# check, which relaxes that one comparison to `>=` specifically so
# "a release exists at my own number" reads as an update. See
# triple-c#32.
HIGHEST=$(git tag -l "v${MAJOR_MINOR}.*" \
| grep -E "^v${MAJOR_MINOR}\.[0-9]+(-mac|-win)?$" \
| sed -E "s/^v${MAJOR_MINOR}\.([0-9]+).*/\1/" \
| sort -n | tail -1 || true)
# Mirrors build-app.yml's own `EXISTING` guard: this workflow is
# also `workflow_dispatch`-able on `main`, not just PR-triggered, so
# HEAD can be a commit a release was already cut from. Without this,
# dispatching a preview there would compute `HIGHEST + 1` — one past
# that release — and produce exactly the "preview outranks
# production" failure triple-c#32 was filed over, just reintroduced
# through the manual-dispatch door instead of the automatic one.
EXISTING=$(git tag --points-at HEAD \
| grep -E "^v${MAJOR_MINOR}\.[0-9]+$" \
| sed -E "s/^v${MAJOR_MINOR}\.([0-9]+)$/\1/" \
| sort -n | tail -1 || true)
if [ -n "$EXISTING" ]; then
echo "HEAD is already tagged v${MAJOR_MINOR}.${EXISTING} — matching it"
PATCH="${EXISTING}"
elif [ -n "$HIGHEST" ]; then
echo "Highest patch already used on this line: ${HIGHEST}"
PATCH=$((HIGHEST + 1))
else
echo "No v${MAJOR_MINOR}.* tag yet — starting this line at .0"
PATCH=0
fi
VERSION="${MAJOR_MINOR}.${PATCH}-preview.${SHORT_SHA}"
SUFFIX="preview.${SHORT_SHA}"
VERSION="${MAJOR_MINOR}.${PATCH}-${SUFFIX}"
echo "VERSION=${VERSION}" >> $GITHUB_OUTPUT
echo "SUFFIX=${SUFFIX}" >> $GITHUB_OUTPUT
echo "Computed preview version: ${VERSION}"
# One release, created once. The three build jobs run concurrently, so
@@ -249,6 +310,13 @@ jobs:
- name: Build Tauri app
working-directory: ./app
env:
# Baked into the binary via `option_env!` in `get_app_version()` —
# the bundle version above stays bare (WiX/MSI's ProductVersion has
# no room for a suffix), so this is the only place a preview build
# can still tell itself apart from a production one. See
# triple-c#32.
TRIPLE_C_BUILD_SUFFIX: ${{ needs.compute-version.outputs.suffix }}
run: |
export PATH="$HOME/.cargo/bin:$PATH"
npx tauri build
@@ -361,6 +429,9 @@ jobs:
- name: Build Tauri app (universal)
working-directory: ./app
env:
# See the matching comment on the Linux job's "Build Tauri app" step.
TRIPLE_C_BUILD_SUFFIX: ${{ needs.compute-version.outputs.suffix }}
run: |
export PATH="$HOME/.cargo/bin:$PATH"
npx tauri build --target universal-apple-darwin
@@ -489,6 +560,8 @@ jobs:
working-directory: ./app
env:
TAURI_CONFIG: "{\"build\":{\"beforeBuildCommand\":\"\"}}"
# See the matching comment on the Linux job's "Build Tauri app" step.
TRIPLE_C_BUILD_SUFFIX: ${{ needs.compute-version.outputs.suffix }}
run: |
set "PATH=%USERPROFILE%\.cargo\bin;C:\Program Files\nodejs;%PATH%"
cargo tauri build
+274
View File
@@ -0,0 +1,274 @@
name: Publish AUR Package
# Builds and pushes the `triple-c-bin` AUR package (packaging/arch/PKGBUILD)
# for a given release, or the latest one if none is given. Manual dispatch
# only — deliberately not triggered by `release` or `push`, for the same
# reason sync-release.yml (removed in triple-c#32) never worked safely as an
# automatic trigger: this repo's releases are assembled by build-app.yml
# across three separate platform jobs, and there is no single automatic event
# that fires only once everything (including the Linux .deb this workflow
# needs) is actually uploaded. A human deciding "this release is ready, go
# package it" is the correct trigger, the same reasoning
# backfill-releases.yml already uses for its own manual-only GitHub sync.
#
# ## What this does and does not do
#
# It renders `packaging/arch/PKGBUILD` for one specific version (real
# download URL, real sha256sums — never guessed; see the resolve-asset step)
# and pushes the rendered PKGBUILD plus a regenerated `.SRCINFO` to AUR. It
# does NOT commit anything back to this repo — `packaging/arch/PKGBUILD` stays
# a hand-maintained template with a placeholder version, and every real,
# published version lives only in AUR's own git history, which is where a
# PKGBUILD's revision history is expected to live. A corollary worth knowing:
# a hand-edit made directly in the AUR repo (outside this workflow) is
# silently overwritten the next time this runs, since every run renders fresh
# from this repo's template rather than starting from AUR's current state.
#
# ## Required secret
#
# `AUR_SSH_PRIVATE_KEY` — an SSH private key registered against an AUR
# account that has already created (or been given co-maintainer access to)
# the `triple-c-bin` package. This workflow cannot create that AUR account or
# register the key for you — both are manual, one-time steps on
# https://aur.archlinux.org. Until this secret exists, every run fails at the
# "Push to AUR" step with a clear error rather than silently doing nothing.
on:
workflow_dispatch:
inputs:
version:
description: >-
Release version to package, without a leading "v" (e.g. "0.4.14").
Leave empty to use the latest published GitHub release.
required: false
env:
GITHUB_REPO: shadowdao/triple-c
AUR_REPO: ssh://aur@aur.archlinux.org/triple-c-bin.git
jobs:
publish:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Resolve version and find the Linux asset
id: resolve
env:
VERSION_INPUT: ${{ inputs.version }}
GH_PAT: ${{ secrets.GH_PAT }}
run: |
set -euo pipefail
# Authenticated when the secret is available (it is, everywhere
# else in this repo's workflows) to avoid the unauthenticated
# 60-requests/hour-per-IP cap; still works without it, just at that
# lower limit, since this hits nothing but a public repo's public
# releases.
AUTH=()
[ -n "${GH_PAT}" ] && AUTH=(-H "Authorization: Bearer ${GH_PAT}")
if [ -z "${VERSION_INPUT}" ]; then
echo "No version given — resolving the latest GitHub release"
RELEASE_JSON=$(curl -fsS "${AUTH[@]}" "https://api.github.com/repos/${GITHUB_REPO}/releases/latest")
else
echo "Using requested version ${VERSION_INPUT}"
RELEASE_JSON=$(curl -fsS "${AUTH[@]}" "https://api.github.com/repos/${GITHUB_REPO}/releases/tags/v${VERSION_INPUT}")
fi
TAG=$(echo "$RELEASE_JSON" | jq -r '.tag_name')
VERSION="${TAG#v}"
echo "Resolved to ${TAG}"
# Discovered from the real release, not assumed: Tauri names the
# asset after `productName` verbatim ("Triple-C"), not the
# lowercase Cargo binary name, and asset naming is exactly the kind
# of thing that silently drifts if a future Tauri upgrade changes
# bundler defaults — a hardcoded pattern here would then 404
# forever until someone noticed. `head -1` guards against a release
# somehow carrying more than one matching asset, which would
# otherwise pass the emptiness check below and then break the
# download step with two URLs on one line.
DEB_URL=$(echo "$RELEASE_JSON" | jq -r '.assets[] | select(.name | endswith("_amd64.deb")) | .browser_download_url' | head -1)
DEB_NAME=$(echo "$RELEASE_JSON" | jq -r '.assets[] | select(.name | endswith("_amd64.deb")) | .name' | head -1)
if [ -z "$DEB_URL" ] || [ "$DEB_URL" = "null" ]; then
echo "No *_amd64.deb asset found on release ${TAG}" >&2
exit 1
fi
echo "Found asset: ${DEB_NAME}"
echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
echo "tag=${TAG}" >> "$GITHUB_OUTPUT"
echo "deb_url=${DEB_URL}" >> "$GITHUB_OUTPUT"
echo "deb_name=${DEB_NAME}" >> "$GITHUB_OUTPUT"
- name: Download the release asset and compute real checksums
id: checksums
env:
DEB_URL: ${{ steps.resolve.outputs.deb_url }}
DEB_NAME: ${{ steps.resolve.outputs.deb_name }}
TAG: ${{ steps.resolve.outputs.tag }}
run: |
set -euo pipefail
curl -fsSL -o "${DEB_NAME}" "${DEB_URL}"
curl -fsSL -o LICENSE "https://raw.githubusercontent.com/${GITHUB_REPO}/${TAG}/LICENSE"
echo "deb_sha256=$(sha256sum "${DEB_NAME}" | cut -d' ' -f1)" >> "$GITHUB_OUTPUT"
echo "license_sha256=$(sha256sum LICENSE | cut -d' ' -f1)" >> "$GITHUB_OUTPUT"
- name: Render PKGBUILD
id: render
env:
VERSION: ${{ steps.resolve.outputs.version }}
DEB_NAME: ${{ steps.resolve.outputs.deb_name }}
DEB_SHA256: ${{ steps.checksums.outputs.deb_sha256 }}
LICENSE_SHA256: ${{ steps.checksums.outputs.license_sha256 }}
run: |
set -euo pipefail
mkdir -p rendered
cp packaging/arch/PKGBUILD rendered/PKGBUILD
cd rendered
# Plain string replacement throughout, not sed — the source URL
# contains slashes and the repo name does too, and getting a sed
# delimiter choice AND its escaping right for that is exactly the
# kind of thing that looks correct, passes review, and breaks the
# next time someone touches it. `re.sub` with `count=1` and an
# exact `.format`-free literal match is boring and that's the
# point: every substitution below fails loudly (an assertion /
# the checks after) rather than silently no-op'ing if the
# template's shape ever drifts from what this expects.
#
# pkgrel resets to 1 for a new pkgver — a packaging-only fix to the
# same upstream version (a dependency bump, say) is what pkgrel is
# for, and this workflow always republishes the current PKGBUILD
# verbatim rather than incrementing anything, so 1 is always
# correct for what this workflow does. It is NOT correct for a
# dependency-only fix republished at the *same* pkgver: pkgrel
# would be forced back to 1, and no existing installation sees an
# upgrade. That case needs a manual pkgrel bump in the template
# before dispatching, which this workflow has no input for.
python3 - "$VERSION" "$DEB_NAME" "$DEB_SHA256" "$LICENSE_SHA256" "$GITHUB_REPO" <<'PY'
import re, sys
version, deb_name, deb_sha, license_sha, github_repo = sys.argv[1:6]
with open("PKGBUILD") as f:
text = f.read()
text, n = re.subn(r"(?m)^pkgver=.*$", f"pkgver={version}", text, count=1)
assert n == 1, "pkgver=... line not found"
text, n = re.subn(r"(?m)^pkgrel=.*$", "pkgrel=1", text, count=1)
assert n == 1, "pkgrel=... line not found"
old_source = (
f'source=("Triple-C_${{pkgver}}_amd64.deb::'
f'https://github.com/{github_repo}/releases/download/v${{pkgver}}/'
f'Triple-C_${{pkgver}}_amd64.deb"'
)
new_source = (
f'source=("{deb_name}::'
f'https://github.com/{github_repo}/releases/download/v{version}/{deb_name}"'
)
assert old_source in text, "source=() line does not match the expected template shape"
text = text.replace(old_source, new_source, 1)
old_sums = "sha256sums=('SKIP'\n 'SKIP')"
assert old_sums in text, "sha256sums=() placeholders not found"
text = text.replace(old_sums, f"sha256sums=('{deb_sha}'\n '{license_sha}')", 1)
with open("PKGBUILD", "w") as f:
f.write(text)
PY
grep -q "pkgver=${VERSION}$" PKGBUILD
! grep -q "SKIP" PKGBUILD
- name: Validate with makepkg and namcap
run: |
set -euo pipefail
# A bind mount (`docker run -v "$PWD/...":/work`) is the more
# obvious way to write this, and was the first draft — but on a
# containerized Gitea act_runner job, `$PWD` is a path inside this
# job's own container, which the daemon's host cannot resolve; the
# mount would silently attach an empty directory instead of failing
# loudly. `docker cp` moves real bytes across that boundary
# regardless of where the daemon actually lives, which is what
# makes this work under both a bind-mount-capable runner and a
# containerized one.
docker pull archlinux:latest
CID=$(docker create -w /work archlinux:latest bash -c '
set -euo pipefail
pacman -Syu --noconfirm --needed base-devel namcap sudo git openssh >/dev/null
useradd -m builder
chown -R builder:builder /work
echo "builder ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/builder
sudo -u builder bash -c "cd /work && makepkg --printsrcinfo > .SRCINFO"
sudo -u builder bash -c "cd /work && makepkg -s --noconfirm"
echo "--- namcap ---"
NAMCAP_OUT=$(sudo -u builder bash -c "cd /work && namcap PKGBUILD *.pkg.tar.*" || true)
echo "$NAMCAP_OUT"
# Matches "triple-c-bin E:", "PKGBUILD (triple-c-bin) E:" and any
# split-package variant ("triple-c-bin-debug E:") alike — namcap
# uses more than one line shape for its two rule families, and
# namcap itself exits 0 regardless of what it reports, so this
# grep is the only thing standing between an E: and a green job.
if echo "$NAMCAP_OUT" | grep -q " E: "; then
echo "namcap reported an error — see above" >&2
exit 1
fi
')
mkdir -p rendered
docker cp rendered/. "${CID}:/work"
# `docker start -a` streams output and its exit code is the
# container's own — the same failure this would have hit with a
# bind mount still fails the job the same way.
docker start -a "${CID}"
docker cp "${CID}:/work/.SRCINFO" rendered/.SRCINFO
docker rm -f "${CID}" >/dev/null
- name: Push to AUR
env:
AUR_SSH_PRIVATE_KEY: ${{ secrets.AUR_SSH_PRIVATE_KEY }}
VERSION: ${{ steps.resolve.outputs.version }}
run: |
set -euo pipefail
if [ -z "${AUR_SSH_PRIVATE_KEY}" ]; then
echo "AUR_SSH_PRIVATE_KEY is not set — see this workflow file's header comment for" >&2
echo "the one-time AUR account setup this needs before it can publish anything." >&2
exit 1
fi
mkdir -p ~/.ssh
# Created with the final mode before any bytes land in it, rather
# than a plain redirect followed by chmod, which leaves the key
# world-readable for whatever window falls between the two calls.
install -m 600 /dev/null ~/.ssh/aur
echo "${AUR_SSH_PRIVATE_KEY}" > ~/.ssh/aur
# TOFU, not verification — accepted here because pinning AUR's
# actual host key needs a value fetched from somewhere trusted
# ahead of time, which this workflow doesn't have, and getting a
# pinned value wrong fails every future run rather than just this
# one. A keyscan failure below surfaces later as an opaque
# "Host key verification failed" rather than a clear one here.
ssh-keyscan -H aur.archlinux.org >> ~/.ssh/known_hosts 2>/dev/null
export GIT_SSH_COMMAND="ssh -i ~/.ssh/aur -o IdentitiesOnly=yes -o UserKnownHostsFile=~/.ssh/known_hosts"
git clone "${AUR_REPO}" aur-repo
cp rendered/PKGBUILD rendered/.SRCINFO aur-repo/
cd aur-repo
git config user.name "Triple-C CI"
git config user.email "noreply@triple-c.invalid"
git add PKGBUILD .SRCINFO
if git diff --cached --quiet; then
echo "No change from what's already published on AUR for ${VERSION}"
exit 0
fi
git commit -m "triple-c-bin: update to ${VERSION}"
# AUR itself uses `master`, which is what a fresh, not-yet-created
# AUR package's empty repo advertises on clone — but the *local*
# branch name after cloning an empty repo falls back to whatever
# this runner's `init.defaultBranch` is if the server sends no
# symref, so naming the destination explicitly is what keeps this
# working if that default is ever `main` instead of `master`.
git push origin HEAD:master
+32
View File
@@ -0,0 +1,32 @@
name: Secret Scan
# **No `paths:` filter, deliberately.** The credential this exists for lived in
# `app/src-tauri/src/docker/container.rs`, which `build.yml` would have skipped —
# that workflow only runs for `container/**`. A scan that can be avoided by
# touching the wrong directory is not a scan.
#
# This is the half of the check that nobody can bypass. The pre-commit hook in
# `.githooks/` is faster and friendlier, but it is opt-in per clone and
# `--no-verify` skips it; both are true of every git hook and neither is fixable
# from inside a repository.
on:
push:
branches: ["**"]
pull_request:
branches: ["**"]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
# The whole tracked tree, not just the diff. Scanning a range is cheaper
# but depends on getting the range right across pushes, force-pushes,
# merges and PR events — and a wrong range fails *open*. The full scan
# takes under half a second on this repository and cannot be evaded by
# arranging for the interesting commit to sit outside the window.
- name: Scan tracked files for credentials
run: sh scripts/scan-secrets.sh --tracked
-59
View File
@@ -1,59 +0,0 @@
name: Sync Release to GitHub
on:
workflow_dispatch:
jobs:
sync-release:
runs-on: ubuntu-latest
steps:
- name: Mirror release to GitHub
env:
GH_PAT: ${{ secrets.GH_PAT }}
GITHUB_REPO: shadowdao/triple-c
RELEASE_TAG: ${{ gitea.event.release.tag_name }}
RELEASE_NAME: ${{ gitea.event.release.name }}
RELEASE_BODY: ${{ gitea.event.release.body }}
IS_PRERELEASE: ${{ gitea.event.release.prerelease }}
IS_DRAFT: ${{ gitea.event.release.draft }}
run: |
set -e
echo "==> Creating release $RELEASE_TAG on GitHub..."
RESPONSE=$(curl -sf -X POST \
-H "Authorization: Bearer $GH_PAT" \
-H "Accept: application/vnd.github+json" \
-H "Content-Type: application/json" \
https://api.github.com/repos/$GITHUB_REPO/releases \
-d "{
\"tag_name\": \"$RELEASE_TAG\",
\"name\": \"$RELEASE_NAME\",
\"body\": $(echo "$RELEASE_BODY" | jq -Rs .),
\"draft\": $IS_DRAFT,
\"prerelease\": $IS_PRERELEASE
}")
UPLOAD_URL=$(echo "$RESPONSE" | jq -r '.upload_url' | sed 's/{?name,label}//')
echo "Release created. Upload URL: $UPLOAD_URL"
echo '${{ toJSON(gitea.event.release.assets) }}' | jq -c '.[]' | while read asset; do
ASSET_NAME=$(echo "$asset" | jq -r '.name')
ASSET_URL=$(echo "$asset" | jq -r '.browser_download_url')
echo "==> Downloading asset: $ASSET_NAME"
curl -sfL -o "/tmp/$ASSET_NAME" "$ASSET_URL"
echo "==> Uploading $ASSET_NAME to GitHub..."
ENCODED_NAME=$(python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1]))" "$ASSET_NAME")
curl -sf -X POST \
-H "Authorization: Bearer $GH_PAT" \
-H "Accept: application/vnd.github+json" \
-H "Content-Type: application/octet-stream" \
--data-binary "@/tmp/$ASSET_NAME" \
"$UPLOAD_URL?name=$ENCODED_NAME"
echo " Uploaded: $ASSET_NAME"
done
echo "==> Release sync complete."
+14
View File
@@ -0,0 +1,14 @@
#!/bin/sh
# Refuse a commit that adds something shaped like a live credential.
#
# Installed by pointing git at this directory:
#
# git config core.hooksPath .githooks
#
# which `npm run hooks` in app/ does for you. It is per-clone — git will not let
# a repository configure its own hooks path, for the obvious reason that cloning
# a repo would then be enough to run its code. So this is opt-in on every
# machine, `--no-verify` skips it, and neither of those is a flaw to fix here:
# the CI job in `.gitea/workflows/build.yml` is the half nobody can bypass. The
# hook exists to tell you in one second rather than in five minutes.
exec "$(git rev-parse --show-toplevel)/scripts/scan-secrets.sh" --staged
+61 -19
View File
@@ -79,23 +79,34 @@ docker exec stdout → tokio task → emit("terminal-output-{sessionId}") → li
- **`components/projects/home/`** — **Project Home**, the main-area view for a project:
Overview / Sessions / Automation / Config / Files. Per-project configuration lives here, not in
modals — see "UI conventions" below.
- **Files is container-side only. It does no host filesystem I/O, and must not grow any.**
The tab lists, opens (text and image viewer), renames and creates folders *inside* the
container: `list_container_files`, `read_container_file`, `rename_container_path`,
`create_container_directory`. There is no upload button, no "Save to host…", and no
drop-into-the-pane. Four successive audits found that host filesystem paths crossing IPC
were where the criticals lived — a caller-named host destination for container-controlled
bytes, an arbitrary host source read into the container, a `link(2)` upload reservation
that succeeded against a directory and failed forever on any filesystem without hard
links — so the feature was narrowed rather than fixed a fifth time. If a host path ever
needs to reach this pane again, the honest shape is for the *backend* to drive
`tauri-plugin-dialog`, so no host path arrives over IPC at all.
- **A file gets *in* by being dropped on the Terminal, and *out* through "Back up
container".** Those two are the whole host↔container story, they predate the Files work,
and their hardening is not to be weakened. `TerminalView`'s `onDragDropEvent` is Tauri's
native drop event (window-wide, so routed by `lib/dropTarget.ts` — geometry for *whose*
drop it is, a document-wide `dropIsBlocked` for whether the app should accept one at all;
keep both halves and keep `PaneVisibility`). Backup is
- **The Files pane's host transfers open their dialog from Rust, and that is the whole
design — do not move it back into the webview.** The tab browses, views (text and image),
renames and creates folders inside the container (`list_container_files`,
`read_container_file`, `rename_container_path`, `create_container_directory`), and it
copies single files in and out (`upload_files_to_container`, `download_container_file`).
The second pair call `pick_files_to_upload` / `pick_save_path`, which drive
`tauri-plugin-dialog` from the *backend*: the webview can ask for a picker and that is the
entirety of its influence — it cannot name a host path as an *input*. The claim stops
there and should not be widened: host paths still travel outward in error text, canonical
ones included. What is closed is the direction that produced the criticals.
That shape is not decoration. Four successive audits found that host filesystem paths
crossing IPC were where the criticals lived — a caller-named host destination for
container-controlled bytes, an arbitrary host source read into the container, a `link(2)`
upload reservation that succeeded against a directory and failed forever on any filesystem
without hard links. The feature was removed rather than fixed a fifth time, and it came
back only in the shape that removes the class: a frontend-driven dialog handing Rust a
string is the exact thing that failed, so re-introducing `open()`/`save()` in `FilesTab`
would undo the whole point while looking like a simplification.
None of the reservation machinery came back with it. There is no destination reservation,
no placeholder rollback and no collision marker — the OS save dialog already asks about
overwriting, and Docker's archive extractor overwrites on upload the way `cp` does.
- **Drag-and-drop is still not it.** There is no drop-into-the-Files-pane and no OS
drag-out; the buttons are the gesture. A file also gets *in* by being dropped on the
Terminal, and a whole tree comes *out* through "Back up container" — those two predate the
Files work and their hardening is not to be weakened. `TerminalView`'s `onDragDropEvent`
is Tauri's native drop event (window-wide, so routed by `lib/dropTarget.ts` — geometry for
*whose* drop it is, a document-wide `dropIsBlocked` for whether the app should accept one
at all; keep both halves and keep `PaneVisibility`). Backup is
`file_commands::download_container_backup`.
- **`resolve_host_path` applies the full lexical predicate twice — as written, and again
after canonicalisation.** That includes the general hidden-component rule, which
@@ -103,8 +114,12 @@ docker exec stdout → tokio task → emit("terminal-output-{sessionId}") → li
`~/.local/share` is refused. Do not narrow it back to a list of "credential" directories.
That was tried, and allow-by-omission let `~/.local/bin` (write there and you own the
user's next shell command), `~/.password-store`, browser profiles and `~/.pki/nssdb`
through a planted symlink with a perfectly visible name. The two callers left are
occasional, so over-refusing is the cheaper mistake.
through a planted symlink with a perfectly visible name. Over-refusing is the cheaper
mistake. Note the cost is real and has grown: of the four callers, the Files pane's two
are routine, and their path comes from a dialog — so an over-catch refuses a destination a
person actually chose (`~/.config` is the common one). Accepted, and not a reason to
narrow the rule, because the terminal drop and `download_container_backup` still take
their host path over IPC and this predicate is their only boundary.
- **OS drag-out is not here.** `tauri-plugin-drag`, `stage_container_file_for_drag` and its
host staging directory were held back for separate hardening and live on
`hold/disk-and-dragout`. Do not re-add `drag:allow-start-drag` or a staging command
@@ -510,6 +525,33 @@ Anthropic and Bedrock deliberately keep Claude Code's own defaults.
`models/project.rs` for anything that should default to true.
- Cross-platform paths: Docker socket is `/var/run/docker.sock` on Linux/macOS, `//./pipe/docker_engine` on Windows
## Secrets
**`scripts/scan-secrets.sh` refuses a commit that adds something shaped like a live
credential.** Enable the hook once per clone with `npm run hooks` (from `app/`), which sets
`core.hooksPath` to `.githooks`. A repository cannot configure its own hooks path — cloning it
would then be enough to run its code — so this is opt-in everywhere, and `--no-verify` skips it.
The `Secret Scan` workflow is the half nobody can bypass; it carries **no `paths:` filter**, on
purpose, because the incident that prompted all this lived in `app/**` and `build.yml` only runs
for `container/**`.
Three rules, and the second half of the third is what keeps it usable: vendor-prefixed tokens
(`ghp_`, `sk-`, `AKIA`, `xox`, …), `BEGIN … PRIVATE KEY` blocks, and an opaque literal assigned to
a secret-shaped name. That last one needs **both** halves — the identifier must read as a
credential *and* the whole literal must be hex or base64 with no word structure. Name-proximity
alone flags `secure::get_project_secret(&id, "aws-secret-access-key")`, which is a keychain key
name; the literal test is what excludes it. Measured against the tree: 0 false positives, and it
catches the real incident (`9b2f4fe`) when replayed.
A line ending `pragma: allowlist secret` is skipped. Make a fixture obviously fake before reaching
for it.
**Why this exists:** `the_custom_env_fingerprint_never_carries_the_value` used the maintainer's
real Gitea **site-admin** token as its fixture — a test about secrets not escaping, leaking one. It
survived 92 commits and fourteen days in the public GitHub mirror, past five audit rounds and two
independent reviews, because every one of them read the code under change and this sat in a test
nobody had reason to open. Fixtures are never live values; there is no case where they need to be.
## Testing
Frontend tests use Vitest with jsdom environment and React Testing Library. Setup file at `src/test/setup.ts`. Run a single test file:
+38 -20
View File
@@ -228,7 +228,7 @@ buttons. Below that are six tabs:
| **Sessions** | Past Claude Code conversations stored on this project's config volume, each with a **Resume** button |
| **Automation** | The scheduled tasks running inside this container — see [Automation & Scheduled Tasks](#automation--scheduled-tasks) |
| **Config** | All per-project configuration — see [Project Configuration](#project-configuration) |
| **Files** | Browse, view and rename files inside the container — see [Files](#files) for how files get in and out |
| **Files** | Browse, view and rename files inside the container, and move files between it and your own machine — see [Files](#files) |
| **Browser** | Watch — and take over — the browser Claude is driving with Playwright, see [The Browser Tab](#the-browser-tab) |
### Sessions
@@ -351,7 +351,7 @@ it. The sidebar row carries only the two hover controls.
| **Force stop** | Project Home header | Starting / Stopping | Interrupts a transition that is stuck |
| **Open Claude Terminal** | Project Home header; sidebar hover control; `Ctrl+T` | Running | Opens a new Claude Code terminal tab |
| **Shell** | Project Home header | Running | Opens a bash login shell tab in the container (no Claude Code) |
| **Files** | Project Home header, and the **Files** tab | Running | Switches to the Files tab to browse, view and rename files inside the container |
| **Files** | Project Home header, and the **Files** tab | Running | Switches to the Files tab to browse, view and rename files inside the container, upload files into it and save one back out |
| **Config** | The **Config** tab | Always | Per-project configuration (most fields need the container stopped) |
| **Back up container** | **⋯** overflow menu | A container exists | Saves a `.tar.gz` archive of the container to a location you choose |
| **Reset container…** | **⋯** overflow menu | Stopped or Error | Destroys the container, snapshot image and both volumes, then recreates from the base image (wipes `~/.claude`) — asks first |
@@ -1170,8 +1170,8 @@ When you scroll up in the terminal to review previous output, a **Jump to Curren
### Files
The **Files** tab of Project Home browses inside a running container. It works entirely on the
container side — it never reads or writes anything on your own machine. You can:
The **Files** tab of Project Home browses inside a running container, and moves files between it
and your own machine. You can:
- **Browse** the container filesystem, starting at `/workspace`, with breadcrumb navigation.
Double-click a folder to open it, or the `..` row to go up; the arrow keys, Home and End move
@@ -1181,32 +1181,50 @@ container side — it never reads or writes anything on your own machine. You ca
- **Rename** an entry, from the row's Rename button or by pressing `F2`. A rename never moves a
file between folders
- **New folder** in the directory on screen
- **Upload…**, from the toolbar, to copy files from your machine into the directory on screen
- **Save to host…**, from a file's own row, to write that one file out to your machine
- **Refresh** the directory listing at any time
The listing shows file names, sizes, and modification dates, and marks symbolic links.
#### Getting files in and out
The Files tab deliberately does **not** copy files between your computer and the container. There
are two supported routes, and they are the ones to use:
**Upload…** opens a file dialog on your machine, and whatever you choose is copied into the
directory currently on screen. Uploaded files arrive owned by you inside the container, not by
root. You can pick several files in one dialog; each is handled on its own, so if a folder or an
over-sized file is among them, it is named in the message and the rest still arrive. Uploads are
capped at **256 MB per file** — for anything larger, mount the folder into the project instead and
skip the copying altogether.
- **To get a file in:** drag it from your desktop and **drop it onto the Terminal tab**. The file
is copied into the container and its path is typed into the terminal for you, ready to hand to
Claude Code. (You can also drop it onto the terminal's *Following* toggle — the whole pane is a
drop target.)
- **To get files out:** use **Back up container** in Project Home's **⋯** overflow menu. It writes
a `.tar.gz` of the workspace and the container's `~/.claude` config to a location you choose.
For a single file, `cat` it in a terminal, or work in a project folder that is mounted from your
host in the first place — those files are already on both sides.
**Save to host…** does the reverse, for one file: a save dialog opens, you choose where the file
goes, and it is written there. The button sits on the file's own row, and only on files. For a
whole directory, use **Back up container** in Project Home's **⋯** overflow menu, which writes a
`.tar.gz` of the workspace and the container's `~/.claude` config to a location you choose — that
is still the right tool for a tree.
Both routes refuse a destination whose path passes through a hidden folder — anything with a
component beginning with `.`, such as `~/.ssh`, `~/.local/bin` or `~/.config`. That rule catches
more than it strictly needs to (a path that happens to resolve through `~/.cache` or
`node_modules/.pnpm` is refused as well), and the refusal says which folder tripped it. Choose a
visible location such as `~/Documents` or `~/Downloads`.
Dragging a file from your desktop and **dropping it onto the Terminal tab** works too, and is often
the quickest way in when you are already typing: the file is copied into the container and its path
is typed into the terminal for you, ready to hand to Claude Code. (The whole terminal pane is a
drop target, including its *Following* toggle.) The Files pane itself is not a drop target.
Both dialogs are opened by Triple-C itself rather than by the page you are looking at. The page
cannot name a place on your machine — it can only ask for a dialog — and nothing is read or written
until you pick somewhere in it. Closing a dialog without choosing is not an error: nothing happens,
and nothing is said about it.
Every one of these routes refuses a location whose path passes through a hidden *folder* — anything
with a component beginning with `.`, such as `~/.ssh`, `~/.cache` or `~/.local/share` — or a system
location, and it checks both the path as written and where it points after any symbolic links. That
rule catches more than it strictly needs to, so now and then it will refuse a place you genuinely
meant, `~/.config` among them. The refusal is a plain sentence saying so; choose a visible location
such as `~/Documents` or `~/Downloads`.
The *file's own name* is a different matter, and dotfiles are fine: `.env`, `.gitignore` and the
rest save normally, since you chose the name in the save dialog yourself. Only the folders on the
way are judged.
If you already keep the project in a folder mounted into the container, the simplest answer is
usually neither of the above: edit the file on your host and it is already inside.
usually none of the above: edit the file on your host and it is already inside.
### Terminal Rendering
+38 -5
View File
@@ -24,7 +24,7 @@ This file is the architectural tour: what each subsystem is and why it works the
- [Permission Modes](#permission-modes)
- [Containers](#containers) — lifecycle, base-image migration, mounts, CA certificates, sibling containers
- [Models and Authentication](#models-and-authentication) — backends, model aliases, gateway, shared token
- [Bridges to the Host](#bridges-to-the-host) — URL relay, auth bridge, browser view
- [Bridges to the Host](#bridges-to-the-host) — URL relay, auth bridge, browser view, host file transfers
- [Inside a Project](#inside-a-project) — capability tiles, Mission Control, web terminal, speech-to-text
- [Key Files](#key-files) · [CSS / Styling Notes](#css--styling-notes) · [Container Image](#container-image)
@@ -105,7 +105,7 @@ configuration. Per-project configuration lives in the Config tab rather than in
| **Sessions** | Past Claude Code conversations read from the config volume, with **Resume** |
| **Automation** | The container's `triple-c-scheduler` tasks — create, edit, enable/disable, run now, read logs, remove, and completion notifications |
| **Config** | Workspace (name, folders), Model (backend), Access (SSH, git, env vars, port mappings), Runtime (permission mode, sandbox, Docker access, Mission Control, instructions, Claude Code settings) |
| **Files** | Browse, view and rename files inside the container. Container-side only: to get a file *in*, drop it on the Terminal tab; to get files *out*, use **Back up container** |
| **Files** | Browse, view, rename and create folders inside the container, upload host files into the directory on screen, and save one file back out to the host — see [Host File Transfers](#host-file-transfers). A whole tree still comes out through **Back up container** |
| **Browser** | Watch and take over the Playwright browser inside the container — see [Browser View](#browser-view) |
Container start/stop progress is reported inline (on the sidebar row and in the Project Home
@@ -442,6 +442,39 @@ per project.
binds, but never `@playwright/cli`, which is the viewer. It is what binds sessions automatically
once Playwright is present — not a setup route.
### Host File Transfers
Four routes move files across the boundary: **Upload…** and the per-row **Save to host…** in the
Files tab, a file dropped onto the Terminal tab, and **Back up container**. All four share one path
policy in `commands/file_commands.rs`.
- **The OS dialogs are opened by Rust, not by the webview.** `upload_files_to_container` and
`download_container_file` drive `tauri-plugin-dialog` themselves and take nothing but a project
id and a container-side path; `FilesTab.tsx` imports no dialog plugin and `useFileManager`'s
`uploadFiles` takes no argument at all. The web UI can ask for a dialog, and that is the whole of
its influence over where a file comes from or goes — it cannot name a host path as an *input*.
This is a boundary rather than a convention: a dialog the page itself opens is only as trustworthy
as the page. Be precise about the limit, though — host paths still travel *outward* in error text,
canonical ones included, so this closes the inbound direction and not both.
- **The dialog's pre-filled name is sanitized, because a container authored it.** On Windows the
save dialog parses its name box as a path, and a container can name a file
`..\..\Users\you\…\Word\STARTUP\x.dotm` — one POSIX segment, so nothing upstream objects.
`suggested_save_name` replaces every separator and every character NTFS refuses, so the string
cannot be a path on any platform this ships to.
- **One policy for every host path.** A source or destination whose path passes through a hidden
folder (`~/.ssh`, `~/.cache`, `~/.local/share`, anything dot-prefixed) or a system location is
refused, and the check is applied both to the path as written and to what it resolves to after
symlinks. It over-catches deliberately, so it will occasionally refuse somewhere a person
genuinely meant — `~/.config`, say — and the refusal is a sentence naming the folder that tripped
it, not an errno.
- **Uploads are capped at 256 MB per file**; past that the answer is a mount, not a copy. One
dialog's selection is handled file by file, so a folder or an oversized file among the selection
is reported by name and does not stop the others. Uploaded files land owned by the container user,
not root. A cancelled dialog is silent — `Ok(None)`, not an error.
- **`download_container_file` is one file and files only** — no button on a folder row. A directory
is what `download_container_backup` is for. There is no drop target on the Files pane; the
Terminal tab keeps the one it has.
## Inside a Project
### Container Introspection (Capability Tiles)
@@ -513,7 +546,7 @@ Triple-C includes optional speech-to-text powered by [Faster Whisper](https://gi
| `app/src/components/projects/home/AutomationTab.tsx` | Scheduler tasks: create, toggle, run now, logs, remove, notifications |
| `app/src/components/projects/home/TaskEditorModal.tsx` | Create/edit a scheduled task; `taskValidation.ts` holds the cron and schedule rules |
| `app/src/components/projects/home/ConfigTab.tsx` | Config sections (Workspace, Model, Access, Runtime) |
| `app/src/components/projects/home/FilesTab.tsx` | Container-side file browser (navigate, view, rename, new folder) |
| `app/src/components/projects/home/FilesTab.tsx` | Container-side file browser (navigate, view, rename, new folder) plus **Upload…** and per-row **Save to host…**; imports no dialog plugin — the dialogs are Rust's |
| `app/src/components/projects/home/BrowserTab.tsx` | Browser view pane: detect, install, watch, take over, pop out |
| `app/src/components/projects/home/OpenPageDialog.tsx` | Open a URL in the container's browser at a chosen viewport |
| `app/src/components/projects/home/ContainerMigrationBanner.tsx` | Base-image staleness banner, migration progress, resume/rollback |
@@ -536,7 +569,7 @@ Triple-C includes optional speech-to-text powered by [Faster Whisper](https://gi
| `app/src/hooks/useTerminal.ts` | Terminal session management (claude and bash modes) |
| `app/src/hooks/useProjectActions.ts` | Start/stop/reset/backup and terminal-opening helpers |
| `app/src/hooks/useContainerMigration.ts` | Staleness polling, migration run, resume and rollback |
| `app/src/hooks/useFileManager.ts` | File browser operations (list, navigate, rename, mkdir) |
| `app/src/hooks/useFileManager.ts` | File browser operations (list, navigate, rename, mkdir) and the host transfers (upload, save one file out); never handles a host path |
| `app/src/hooks/useClaudeAuth.ts` | Shared-token status and acquisition |
| `app/src/hooks/useSTT.ts` | Speech-to-text recording, transcription, and container management |
| `app/src/lib/urlRelay.ts` | Host-side relay validation: OSC 7777 parsing, http/https allowlist, rate limiting |
@@ -561,7 +594,7 @@ Triple-C includes optional speech-to-text powered by [Faster Whisper](https://gi
| `app/src-tauri/src/commands/inspect_commands.rs` | Read-only container views: sessions, capabilities, scheduler tasks |
| `app/src-tauri/src/commands/auth_token_commands.rs` | `claude setup-token` flow, redaction, keychain storage |
| `app/src-tauri/src/commands/auth_bridge_commands.rs` | Auth bridge enable/status commands |
| `app/src-tauri/src/commands/file_commands.rs` | Container-side file commands (list, read, rename, mkdir) plus `download_container_backup` |
| `app/src-tauri/src/commands/file_commands.rs` | Container-side file commands (list, read, rename, mkdir), the host transfers `upload_files_to_container` and `download_container_file` — each opening its own OS dialog here in Rust — plus `download_container_backup`, and the hidden-folder path policy all of them share |
| `app/src-tauri/src/commands/stt_commands.rs` | STT start/stop/transcribe Tauri commands |
| `app/src-tauri/src/commands/web_terminal_commands.rs` | Web terminal start/stop/status Tauri commands |
| `app/src-tauri/src/models/project.rs` | Project struct (backend, `PermissionMode`, Docker access, Claude Code settings, Mission Control, auth bridge, browser view, CA path, shared-token opt-out) |
+11 -6
View File
@@ -412,13 +412,18 @@ triple-c/
│
├── .gitea/
│ └── workflows/
│ ├── build-app.yml # Build Tauri app (Linux/macOS/Windows)
│ ├── build-app.yml # Build Tauri app (Linux/macOS/Windows); mirrors releases to GitHub inline
│ ├── build-app-preview.yml # Preview builds
│ ├── build.yml # Build container image (multi-arch)
│ ├── build-stt.yml # Build the STT image
│ ├── sync-release.yml # Mirror releases to GitHub
│ ├── backfill-releases.yml # Bulk copy releases to GitHub
│ └── cleanup-releases.yml # Prune old releases
│ ├── cleanup-releases.yml # Prune old releases
│ └── publish-aur-package.yml # Publish triple-c-bin to the AUR (packaging/arch/)
│
├── packaging/
│ └── arch/ # AUR triple-c-bin package — see packaging/arch/README.md
│ ├── PKGBUILD
│ └── README.md
│
└── app/ # Tauri v2 desktop application
├── package.json # React, xterm.js, zustand, tailwindcss
@@ -436,7 +441,7 @@ triple-c/
│ │ ├── useClaudeAuth.ts # Shared token status + acquisition
│ │ ├── useContainerProgress.ts # container-progress events → inline progress
│ │ ├── useDocker.ts # Docker status, image build/pull
│ │ ├── useFileManager.ts # File browser operations
│ │ ├── useFileManager.ts # File browser operations + host transfers
│ │ ├── useInstallHelper.ts # Guided Docker installation
│ │ ├── useKeyboardShortcuts.ts # Ctrl+T / Ctrl+Shift+W / Ctrl+Tab / Ctrl+1..9
│ │ ├── useProjectActions.ts # Start/stop/reset/backup, open terminals
@@ -464,7 +469,7 @@ triple-c/
│ │ │ ├── SessionsTab.tsx # Past Claude sessions + Resume
│ │ │ ├── AutomationTab.tsx # Scheduler tasks + notifications
│ │ │ ├── ConfigTab.tsx # Config section host
│ │ │ ├── FilesTab.tsx # In-container file browser
│ │ │ ├── FilesTab.tsx # In-container file browser, upload / save to host
│ │ │ ├── CapabilityTiles.tsx # Read-only capability counts
│ │ │ ├── format.ts # Age / size / uptime formatting
│ │ │ └── config/ # WorkspaceSection, ModelSection,
@@ -504,7 +509,7 @@ triple-c/
│ ├── auth_token_commands.rs # claude setup-token flow, redaction, keychain
│ ├── aws_commands.rs # AWS profile/region discovery
│ ├── docker_commands.rs # Docker status, image ops
│ ├── file_commands.rs # File browser (browse, view, rename)
│ ├── file_commands.rs # File browser + host transfers (Rust-opened dialogs)
│ ├── help_commands.rs # Serves HOW-TO-USE.md to the Help dialog
│ ├── inspect_commands.rs # Sessions, capabilities, scheduler tasks
│ ├── install_helper_commands.rs # Guided Docker installation
+2 -1
View File
@@ -9,7 +9,8 @@
"preview": "vite preview",
"tauri": "tauri",
"test": "vitest run",
"test:watch": "vitest"
"test:watch": "vitest",
"hooks": "git -C .. config core.hooksPath .githooks && echo \"pre-commit secret scan enabled\""
},
"dependencies": {
"@tauri-apps/api": "^2",
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large Load Diff
+370 -17
View File
@@ -2,7 +2,7 @@ use tauri::{Emitter, State};
use crate::commands::aws_commands;
use crate::docker;
use crate::models::{container_config, AppSettings, Backend, BedrockAuthMethod, Project, ProjectPath, ProjectStatus};
use crate::models::{container_config, AppSettings, Backend, BedrockAuthMethod, Project, ProjectPath, ProjectRemovalReport, ProjectResetOutcome, ProjectStatus};
use crate::storage::secure;
use crate::AppState;
@@ -696,7 +696,7 @@ pub async fn add_project(
pub async fn remove_project(
project_id: String,
state: State<'_, AppState>,
) -> Result<(), String> {
) -> Result<ProjectRemovalReport, String> {
// **H-2: the only writer of these three categories that held nothing.**
// This purges migration artifacts, removes `triple-c-snapshot-{id}` and
// both named volumes — and a compaction resolves that same tag when its
@@ -722,12 +722,76 @@ pub async fn remove_project(
// holding an entire snapshot image that nothing will ever reference again.
crate::commands::migration_commands::purge_migration_artifacts(&project_id).await;
// Stop and remove container if it exists
if let Some(ref project) = state.projects_store.get(&project_id) {
if let Some(ref container_id) = project.container_id {
// Stop and remove container if it exists. Everything named in `report`
// below is what will be unreachable the moment this function drops the
// project record — see [`ProjectRemovalReport`] and
// `storage::pending_cleanup`, which is what makes it reachable anyway.
let mut report = ProjectRemovalReport::default();
let existing_project = state.projects_store.get(&project_id);
if let Some(ref project) = existing_project {
// Resolved via `find_existing_container` unconditionally rather than
// trusting `project.container_id` — that field can be *stale*, not
// just absent: `start_project_container_locked`'s recreate path
// removes the old container, creates a new one, and does not persist
// the new id until after `start_container` succeeds, so a start
// failure in between (a missing `/dev/net/tun`, an image that exits
// immediately) leaves the stored id pointing at a container that no
// longer exists while a live one sits under the same deterministic
// name. Removing by a stale id then 404s — success as far as Docker
// is concerned — while the real container survives to block every
// subsequent volume removal with a 409, with nothing in the report
// ever naming it. `find_existing_container` is what every other
// destroyer of a project's container already resolves through
// (`start_project_container`, migration's recreate paths) for this
// exact reason.
//
// A `Docker unreachable` error here is treated as "assume a
// container is still there" rather than "assume none is", matching
// `remove_volumes_by_name`'s fail-closed handling of the same
// situation — the alternative silently drops the one resource most
// likely to block everything else if it does exist.
//
// Exec sessions are closed for `project.container_id` unconditionally,
// before the lookup above and regardless of whether it succeeds —
// that is host-side state with no Docker dependency, so it must not
// wait on a daemon that might not answer. Resolving through
// `find_existing_container` instead of using it directly would leave
// these open in exactly the two cases this whole change exists to
// handle: Docker unreachable (no id resolved, no way to ever close
// them again once the project record is gone) and the stale-id race
// (sessions were opened against the container that actually exists,
// which is what gets resolved below, not the stored id).
if let Some(ref stored_id) = project.container_id {
state.exec_manager.close_sessions_for_container(stored_id).await;
}
let container_ref = match docker::find_existing_container(project).await {
Ok(found) => found,
Err(e) => {
log::warn!(
"Could not check for an existing container for project {}: {}",
project_id, e
);
report.container = Some(project.container_name());
None
}
};
if let Some(ref container_id) = container_ref {
if project.container_id.as_deref() != Some(container_id.as_str()) {
state.exec_manager.close_sessions_for_container(container_id).await;
}
let _ = docker::stop_container(container_id).await;
let _ = docker::remove_container(container_id).await;
if let Err(e) = docker::remove_container(container_id).await {
log::warn!(
"Failed to remove container {} for project {}: {}",
container_id, project_id, e
);
// Recorded by name, not id: the name is the stable handle a
// later retry can still resolve (Docker's remove-container
// call accepts either), and it is what `container_ref` above
// falls back to finding in the first place.
report.container = Some(project.container_name());
}
}
// Legacy MCP cleanup (pre-MCP-removal installs): drop any leftover MCP
@@ -738,10 +802,9 @@ pub async fn remove_project(
// Clean up the snapshot image + volumes
if let Err(e) = docker::remove_snapshot_image(project).await {
log::warn!("Failed to remove snapshot image for project {}: {}", project_id, e);
report.image = Some(docker::get_snapshot_image_name(project));
}
if let Err(e) = docker::remove_project_volumes(project).await {
log::warn!("Failed to remove project volumes for project {}: {}", project_id, e);
}
report.volumes = docker::remove_project_volumes(project).await;
}
// Clean up keychain secrets for this project
@@ -749,7 +812,216 @@ pub async fn remove_project(
log::warn!("Failed to delete keychain secrets for project {}: {}", project_id, e);
}
state.projects_store.remove(&project_id)
if !report.is_clean() {
let record = crate::storage::pending_cleanup::PendingCleanup {
project_id: project_id.clone(),
project_name: existing_project.map(|p| p.name).unwrap_or_default(),
container_id: report.container.clone(),
image: report.image.clone(),
volumes: report.volumes.clone(),
recorded_at: chrono::Utc::now().to_rfc3339(),
};
match crate::storage::pending_cleanup::save(&record) {
Ok(()) => {
report.retry_scheduled = true;
log::warn!(
"Project {} removed; could not confirm these Docker resources were removed: \
{:?} — recorded for automatic retry on next launch",
project_id, report
);
}
Err(e) => {
report.retry_scheduled = false;
log::error!(
"Project {} removed; could not confirm these Docker resources were removed \
({:?}), and the pending-cleanup record could not be written ({}) — nothing \
will retry removing them",
project_id, report, e
);
}
}
}
// The pending-cleanup record above must not outlive the project record it
// describes: if the store's own write fails (full disk, permissions) the
// project is still on disk and will reload on the next launch, but the
// record would tell startup housekeeping to delete its container and
// volumes out from under it. Roll the record back rather than leaving
// that mismatch for the retry to discover the hard way.
//
// This is a second, narrower line of defence, not the only one — a crash
// between the `save` above and the `remove` below leaves exactly the same
// mismatch with no error for either side to catch, which is why
// `retry_pending_cleanup_logged` also refuses to act on a record whose
// project is still listed in `projects.json`. Belt and suspenders: a
// caught failure here is handled immediately rather than waiting for the
// next launch to notice.
if let Err(e) = state.projects_store.remove(&project_id) {
if !report.is_clean() {
if let Err(clear_err) = crate::storage::pending_cleanup::clear(&project_id) {
log::error!(
"Project {} was not removed ({}), and its pending-cleanup record could not \
be rolled back either ({}) — it will name this still-live project until \
startup housekeeping's own guard clears it",
project_id, e, clear_err
);
}
}
return Err(e);
}
Ok(report)
}
/// Retry every pending-cleanup record left behind by a [`remove_project`]
/// that could not finish. Run once at startup alongside the other reapers
/// (see `lib.rs`'s "Startup disk housekeeping" block) — never on a timer and
/// never blocking anything, since a locked volume or an in-use image can sit
/// unresolved for an arbitrary amount of time and the daemon may not even be
/// up yet.
///
/// Not a `#[tauri::command]`: nothing in the UI surfaces this list yet
/// (deliberately — see `SnapshotSweepReport`'s doc comment for the same
/// reasoning), so there is no IPC contract to keep. A record that still has
/// leftovers after this is written back so the next run does not lose track
/// of what changed; one that is now empty is deleted.
///
/// Takes the `ProjectsStore` so it can refuse to touch a project that is
/// still live: `remove_project` writes a pending-cleanup record durably
/// (fsync'd) *before* it asks the store to drop the project, and that
/// store write is a plain `fs::write` with no fsync of its own. A crash or
/// power loss in the gap between the two — or the store write failing
/// outright, on top of the round-2 fix that only rolls the record back when
/// that failure is caught in-process — can leave a record on disk pointing
/// at a project `projects.json` still lists. Without this check, the very
/// first retry after such a crash deletes that project's container,
/// snapshot image and *both volumes, including the one holding the OAuth
/// credential and every session transcript*, out from under a project the
/// user still sees in the sidebar. A record whose project still exists is
/// therefore always stale — cleared without touching Docker, not retried.
pub async fn retry_pending_cleanup_logged(projects_store: &crate::storage::projects_store::ProjectsStore) {
let records = crate::storage::pending_cleanup::list();
if records.is_empty() {
return;
}
let mut cleaned = 0usize;
let mut still_pending = 0usize;
for mut record in records {
if projects_store.get(&record.project_id).is_some() {
log::warn!(
"Pending cleanup record for project {} ({}) names a project that still exists — \
clearing the record without touching Docker rather than risk deleting a live \
project's resources",
record.project_id, record.project_name
);
if let Err(e) = crate::storage::pending_cleanup::clear(&record.project_id) {
log::error!(
"Could not clear the stale pending-cleanup record for still-live project {} \
({}): {}",
record.project_id, record.project_name, e
);
}
continue;
}
if let Some(container_id) = record.container_id.take() {
match docker::remove_container(&container_id).await {
Ok(()) => {}
Err(e) => {
log::warn!(
"Pending cleanup: still could not remove container {} for project {} \
({}): {}",
container_id, record.project_id, record.project_name, e
);
record.container_id = Some(container_id);
}
}
}
if let Some(image) = record.image.take() {
match docker::remove_image_by_name(&image).await {
Ok(()) => {}
Err(e) => {
log::warn!(
"Pending cleanup: still could not remove image {} for project {} ({}): {}",
image, record.project_id, record.project_name, e
);
record.image = Some(image);
}
}
}
if !record.volumes.is_empty() {
record.volumes = docker::remove_volumes_by_name(&record.volumes).await;
}
if record.is_empty() {
if let Err(e) = crate::storage::pending_cleanup::clear(&record.project_id) {
log::warn!(
"Pending cleanup for project {} ({}) finished but the record could not be \
deleted: {}",
record.project_id, record.project_name, e
);
}
cleaned += 1;
} else {
still_pending += 1;
// `recorded_at` is otherwise write-only — nothing read it back,
// which is exactly the shape `storage::migration_store` calls out
// as a bug in its own history ("nothing ever removed them"). A
// record that has failed every retry for a week is no longer
// routine: escalate the log level so it is not indistinguishable
// from one seen for the first time.
match pending_cleanup_is_stale(&record.recorded_at, chrono::Utc::now()) {
Some(true) => {
log::error!(
"Pending cleanup for project {} ({}) has not succeeded in over {} \
days: {:?} — this may need a manual `docker volume rm` / \
`docker rmi` / `docker rm`",
record.project_id, record.project_name, PENDING_CLEANUP_STALE_AFTER_DAYS, record
);
}
Some(false) => {}
// Silent otherwise would mean a record with a corrupted
// timestamp never escalates and nothing says why.
None => log::debug!(
"Pending cleanup record for project {} ({}) has an unreadable recorded_at \
({:?}) — its age cannot be tracked",
record.project_id, record.project_name, record.recorded_at
),
}
if let Err(e) = crate::storage::pending_cleanup::save(&record) {
log::warn!(
"Could not update pending cleanup record for project {} ({}): {}",
record.project_id, record.project_name, e
);
}
}
}
log::info!(
"Pending cleanup retry: {} project(s) fully cleaned up, {} still have leftovers",
cleaned, still_pending
);
}
/// After this many days of a pending-cleanup record failing every retry,
/// `retry_pending_cleanup_logged` escalates its log line from `warn` to
/// `error` — see the comment at its call site.
const PENDING_CLEANUP_STALE_AFTER_DAYS: i64 = 7;
/// Whether a pending-cleanup record's `recorded_at` is older than
/// [`PENDING_CLEANUP_STALE_AFTER_DAYS`], measured against `now`. `None` means
/// the timestamp could not be parsed at all — a corrupted or (hypothetically)
/// hand-edited record — which callers must not silently treat as "not stale"
/// without saying why. `now` is a parameter rather than read internally so
/// this is testable without a live clock.
fn pending_cleanup_is_stale(recorded_at: &str, now: chrono::DateTime<chrono::Utc>) -> Option<bool> {
let recorded = chrono::DateTime::parse_from_rfc3339(recorded_at)
.ok()?
.with_timezone(&chrono::Utc);
Some(now.signed_duration_since(recorded) > chrono::Duration::days(PENDING_CLEANUP_STALE_AFTER_DAYS))
}
#[tauri::command]
@@ -1226,7 +1498,7 @@ pub async fn rebuild_project_container(
project_id: String,
app_handle: tauri::AppHandle,
state: State<'_, AppState>,
) -> Result<Project, String> {
) -> Result<ProjectResetOutcome, String> {
// Reset deletes both volumes and the snapshot image. Doing that while a
// migration is mid-flight pulls the ground out from under it and leaves an
// orphan migration record pointing at images that no longer exist — and
@@ -1253,25 +1525,58 @@ pub async fn rebuild_project_container(
// `start_project_container` below re-arms it against the new one.
state.auth_bridge.stop(&project_id).await;
// Remove existing container
if let Some(ref container_id) = project.container_id {
// Remove existing container. Resolved via `find_existing_container`
// unconditionally, not `project.container_id` — see the long comment in
// `remove_project` for why that field can be stale, not just absent. A
// container this misses blocks the volume removal immediately below with
// a 409, and Reset silently keeping the old volumes is exactly the bug
// this whole change is closing. Unlike `remove_project`'s best-effort
// handling of the same lookup failing, `?` here aborts Reset outright:
// every step after this one needs Docker too, so there is no useful
// partial progress to make without it.
// Closed for the stored id unconditionally, then again for the resolved
// one if it differs — see the matching comment in `remove_project` for
// why the stale-id race can leave sessions open under either identity.
if let Some(ref stored_id) = project.container_id {
state.exec_manager.close_sessions_for_container(stored_id).await;
}
let container_ref = docker::find_existing_container(&project).await?;
if let Some(ref container_id) = container_ref {
if project.container_id.as_deref() != Some(container_id.as_str()) {
state.exec_manager.close_sessions_for_container(container_id).await;
}
let _ = docker::stop_container(container_id).await;
docker::remove_container(container_id).await?;
state.projects_store.set_container_id(&project_id, None)?;
}
// Remove snapshot image + volumes so Reset creates from the clean base image
// Remove snapshot image + volumes so Reset creates from the clean base
// image. Both leftovers are surfaced, not just logged — an image that
// survives is the more serious of the two, since
// `start_project_container_locked` below builds from
// `triple-c-snapshot-{id}:latest` whenever it exists, so a leftover image
// means Reset silently rebuilds the exact system layer it promised to
// discard. No pending-cleanup record for either: unlike `remove_project`,
// Reset keeps the project record, so a later Reset attempt can retry
// these itself rather than needing startup housekeeping to do it.
let mut leftover_image = None;
if let Err(e) = docker::remove_snapshot_image(&project).await {
log::warn!("Failed to remove snapshot image for project {}: {}", project_id, e);
leftover_image = Some(docker::get_snapshot_image_name(&project));
}
if let Err(e) = docker::remove_project_volumes(&project).await {
log::warn!("Failed to remove project volumes for project {}: {}", project_id, e);
let leftover_volumes = docker::remove_project_volumes(&project).await;
if leftover_image.is_some() || !leftover_volumes.is_empty() {
log::warn!(
"Reset for project {} could not fully clean up — image: {:?}, volumes: {:?} — the \
new container may be built from, or reuse, old contents instead of starting clean",
project_id, leftover_image, leftover_volumes
);
}
// Start fresh. The locked variant, because `_guard` above is this project's
// claim and the public command would be refused by it.
start_project_container_locked(project_id, app_handle, state).await
let project = start_project_container_locked(project_id, app_handle, state).await?;
Ok(ProjectResetOutcome { project, leftover_image, leftover_volumes })
}
/// Reconcile project statuses against actual Docker container state.
@@ -1379,6 +1684,54 @@ fn default_docker_socket() -> String {
mod tests {
use super::*;
// ── Pending-cleanup aging ────────────────────────────────────────────
#[test]
fn a_record_younger_than_the_threshold_is_not_stale() {
let now = "2026-08-25T00:00:00Z".parse().unwrap();
let recorded_at = "2026-08-19T00:00:00Z"; // 6 days before `now`
assert_eq!(pending_cleanup_is_stale(recorded_at, now), Some(false));
}
#[test]
fn a_record_exactly_at_the_threshold_is_not_yet_stale() {
let now = "2026-08-25T00:00:00Z".parse().unwrap();
let recorded_at = "2026-08-18T00:00:00Z"; // exactly 7 days before `now`
assert_eq!(
pending_cleanup_is_stale(recorded_at, now),
Some(false),
"the boundary itself must not already read as stale"
);
}
#[test]
fn a_record_older_than_the_threshold_is_stale() {
let now = "2026-08-25T00:00:00Z".parse().unwrap();
let recorded_at = "2026-08-17T00:00:00Z"; // 8 days before `now`
assert_eq!(pending_cleanup_is_stale(recorded_at, now), Some(true));
}
/// A clock that ran fast when the record was written leaves a timestamp
/// in the future. This must read as "not stale" rather than underflow or
/// panic — `signed_duration_since` returns a negative `Duration` here,
/// which compares less than any positive threshold correctly.
#[test]
fn a_timestamp_in_the_future_is_not_stale() {
let now = "2026-08-25T00:00:00Z".parse().unwrap();
let recorded_at = "2026-08-26T00:00:00Z"; // one day after `now`
assert_eq!(pending_cleanup_is_stale(recorded_at, now), Some(false));
}
/// A corrupted or hand-edited `recorded_at` must not silently read as
/// "not stale" through some default — callers need to be able to tell
/// "definitely not stale" apart from "cannot tell".
#[test]
fn an_unparseable_recorded_at_reports_unknown_rather_than_not_stale() {
let now = "2026-08-25T00:00:00Z".parse().unwrap();
assert_eq!(pending_cleanup_is_stale("not a timestamp", now), None);
assert_eq!(pending_cleanup_is_stale("", now), None);
}
fn path(host: &str, mount: &str) -> ProjectPath {
ProjectPath {
host_path: host.to_string(),
@@ -202,8 +202,11 @@ pub async fn upload_host_file_to_terminal(
// (`~/.ssh`, `~/.aws`, `~/.local/bin`) or a system location — applied to
// the path with its symlinks already resolved, so a visible directory that
// *leads* to one of those is refused too. What comes back is that resolved
// path, and it is what gets opened. This is now one of only two commands
// that touch a host path at all; the other is `download_container_backup`.
// path, and it is what gets opened. Four commands touch a host path now,
// but only two take it *over IPC*: this one and `download_container_backup`.
// The Files pane's `download_container_file` and `upload_files_to_container`
// open their dialog from Rust instead, so for them the policy above is
// defence in depth and for these two it is the boundary itself.
// The name is taken from the path the user actually dropped, *before*
// resolution. Deriving it from the resolved path renames the file behind
// the user's back: dropping `~/Downloads/latest.log`, where `latest.log` is
@@ -222,8 +225,9 @@ pub async fn upload_host_file_to_terminal(
// with no writer, with no timeout anywhere on this path. The upload then
// never returns, the toast sticks on "Adding N files…" for the session and
// the rest of the batch is abandoned. Sockets and device nodes are the same
// shape. With the Files tab's upload removed, this is the only route for
// getting a file into a container, so it is the wrong place to be clever.
// shape. This is one of two routes for getting a host file into a
// container (the Files pane's upload is the other), so it is the wrong
// place to be clever.
if !meta.is_file() {
return Err(if meta.is_dir() {
format!("{} is a directory — drop individual files", host_path)
@@ -260,7 +264,13 @@ pub async fn upload_host_file_to_terminal(
.await?;
let file_name = format!("triple-c-drops/{}", base);
crate::docker::exec::upload_host_file_to_container(&container_id, &host_path, &file_name).await
crate::docker::exec::upload_host_file_to_container(
&container_id,
&host_path,
"/tmp",
&file_name,
)
.await
}
#[tauri::command]
+201 -24
View File
@@ -16,9 +16,37 @@ const REGISTRY_API_BASE: &str =
const GHCR_TOKEN_URL: &str =
"https://ghcr.io/token?scope=repository:shadowdao/triple-c-sandbox:pull";
/// The build-time preview suffix, if one was baked in and isn't blank.
///
/// The bundle version itself (`tauri.conf.json`, `Cargo.toml`, `package.json`)
/// is never given a `-preview.<sha>` suffix — `build-app-preview.yml` strips
/// it before patching those files, because the Windows MSI's `ProductVersion`
/// is a fixed-width numeric field with no room for one, and nothing here can
/// verify a change to that without an actual Windows build. `TRIPLE_C_BUILD_SUFFIX`
/// is the workaround: set as a build-time env var in the preview workflow
/// only, so `option_env!` bakes it into the binary without the bundle version
/// ever seeing it. A production build sets nothing, so `option_env!` reads
/// `None` here — see triple-c#32.
///
/// The single source of truth for "is this a preview build": both
/// `get_app_version()` (what the About panel shows) and `check_for_updates()`
/// (whether a same-numbered release counts as an update — see `pick_update`)
/// read this rather than each calling `option_env!` themselves, so the two
/// can never silently disagree about which build this is.
fn preview_build_suffix() -> Option<&'static str> {
option_env!("TRIPLE_C_BUILD_SUFFIX").filter(|s| !s.is_empty())
}
fn format_app_version(base: &str, build_suffix: Option<&str>) -> String {
match build_suffix {
Some(suffix) if !suffix.is_empty() => format!("{}-{}", base, suffix),
_ => base.to_string(),
}
}
#[tauri::command]
pub fn get_app_version() -> String {
env!("CARGO_PKG_VERSION").to_string()
format_app_version(env!("CARGO_PKG_VERSION"), preview_build_suffix())
}
#[tauri::command]
@@ -51,30 +79,20 @@ pub async fn check_for_updates() -> Result<Option<UpdateInfo>, String> {
&[".AppImage", ".deb", ".rpm"]
};
// Filter releases that have at least one asset matching the current platform
let platform_releases: Vec<&GitHubRelease> = releases
.iter()
.filter(|r| {
r.assets.iter().any(|a| {
platform_extensions.iter().any(|ext| a.name.ends_with(ext))
})
})
.collect();
// `current_version` above is always the bare, stripped `CARGO_PKG_VERSION`
// — the preview workflow patches `Cargo.toml` with that before compiling,
// never the `-preview.<sha>`-suffixed one `get_app_version()` reports —
// so a preview build and the release it precedes compile to the identical
// numeric tuple by construction (see `build-app-preview.yml`'s "highest
// tag used, +1" computation). A strict `>` therefore never fires for the
// one release a preview most needs to be offered. `is_preview_build`
// relaxes that one comparison to `>=` so "there is a real release at my
// own number" reads as an update, without touching the production case
// — see `pick_update`.
let is_preview_build = preview_build_suffix().is_some();
// Find the latest release with a higher semver version
let mut best: Option<(&GitHubRelease, (u32, u32, u32))> = None;
for release in &platform_releases {
if let Some(ver) = parse_semver_from_tag(&release.tag_name) {
if ver > current_semver {
if best.is_none() || ver > best.unwrap().1 {
best = Some((release, ver));
}
}
}
}
match best {
Some((release, _)) => {
match pick_update(&releases, current_semver, platform_extensions, is_preview_build) {
Some(release) => {
// Only include assets matching the current platform
let assets = release
.assets
@@ -105,6 +123,51 @@ pub async fn check_for_updates() -> Result<Option<UpdateInfo>, String> {
}
}
/// Pick the newest available update out of a release list, or `None` if
/// nothing beats `current_semver`. Pure and synchronous — split out of
/// `check_for_updates` so the prerelease/platform/version filtering can be
/// tested without a live HTTP call.
///
/// Three filters, all of which must pass: not a prerelease (see the long
/// comment on `GitHubRelease::prerelease`), at least one asset for this
/// platform, and a tag that parses as semver *and* beats what is running. A
/// tag that does not parse — `preview-<sha>` (the shape
/// `build-app-preview.yml` actually creates release tags with), most
/// realistically — is skipped rather than erroring, the same as it always
/// has been; nothing here changes what an update tag is expected to look
/// like, only what channel it is allowed to come from.
///
/// `is_preview_build` relaxes "beats" from `>` to `>=`. A preview build's
/// `current_semver` is the bare number it was compiled with, which is by
/// construction identical to the release it precedes — see the comment at
/// `check_for_updates`'s call site — so a strict `>` would never fire for
/// exactly the release a preview install most needs to be told about.
fn pick_update<'a>(
releases: &'a [GitHubRelease],
current_semver: (u32, u32, u32),
platform_extensions: &[&str],
is_preview_build: bool,
) -> Option<&'a GitHubRelease> {
releases
.iter()
.filter(|r| !r.prerelease)
.filter(|r| {
r.assets
.iter()
.any(|a| platform_extensions.iter().any(|ext| a.name.ends_with(ext)))
})
.filter_map(|r| parse_semver_from_tag(&r.tag_name).map(|ver| (r, ver)))
.filter(|(_, ver)| {
if is_preview_build {
*ver >= current_semver
} else {
*ver > current_semver
}
})
.max_by_key(|(_, ver)| *ver)
.map(|(r, _)| r)
}
/// Parse a semver string like "0.2.5" -> (0, 2, 5)
fn parse_semver(version: &str) -> Option<(u32, u32, u32)> {
let clean = version.trim_start_matches('v');
@@ -131,6 +194,120 @@ fn extract_version_from_tag(tag: &str) -> Option<String> {
Some(format!("{}.{}.{}", major, minor, patch))
}
#[cfg(test)]
mod tests {
use super::*;
use crate::models::GitHubAsset;
// ── format_app_version ──────────────────────────────────────────────
#[test]
fn a_production_build_reports_the_bare_version() {
assert_eq!(format_app_version("0.4.12", None), "0.4.12");
// An empty env var (set but blank) must not print a trailing dash.
assert_eq!(format_app_version("0.4.12", Some("")), "0.4.12");
}
#[test]
fn a_preview_build_reports_its_suffix() {
assert_eq!(
format_app_version("0.4.12", Some("preview.a1b2c3d")),
"0.4.12-preview.a1b2c3d"
);
}
// ── pick_update ──────────────────────────────────────────────────────
fn release(tag: &str, prerelease: bool, asset_names: &[&str]) -> GitHubRelease {
GitHubRelease {
tag_name: tag.to_string(),
html_url: format!("https://example.invalid/{}", tag),
body: String::new(),
assets: asset_names
.iter()
.map(|name| GitHubAsset {
name: name.to_string(),
browser_download_url: String::new(),
size: 0,
})
.collect(),
published_at: "2026-01-01T00:00:00Z".to_string(),
prerelease,
}
}
const LINUX_EXTENSIONS: &[&str] = &[".AppImage", ".deb", ".rpm"];
#[test]
fn a_prerelease_is_never_offered_even_if_its_tag_would_otherwise_win() {
let releases = vec![release("v9.9.9", true, &["app-9.9.9.AppImage"])];
assert!(pick_update(&releases, (0, 4, 10), LINUX_EXTENSIONS, false).is_none());
}
#[test]
fn a_release_with_no_asset_for_this_platform_is_skipped() {
let releases = vec![release("v0.4.12", false, &["app-0.4.12.msi"])];
assert!(pick_update(&releases, (0, 4, 10), LINUX_EXTENSIONS, false).is_none());
}
#[test]
fn a_release_that_is_not_newer_is_not_offered() {
let releases = vec![release("v0.4.10", false, &["app.AppImage"])];
assert!(pick_update(&releases, (0, 4, 10), LINUX_EXTENSIONS, false).is_none());
}
#[test]
fn an_untagged_or_unparseable_release_is_skipped_not_fatal() {
// A `-preview.<sha>` tag is exactly the shape this must not choke on
// or mistake for an update — it simply never parses as a bare semver.
let releases = vec![
release("preview-a1b2c3d", false, &["app.AppImage"]),
release("v0.4.12", false, &["app.AppImage"]),
];
let best = pick_update(&releases, (0, 4, 10), LINUX_EXTENSIONS, false).unwrap();
assert_eq!(best.tag_name, "v0.4.12");
}
#[test]
fn the_highest_qualifying_version_wins_not_the_first_or_last_in_the_list() {
let releases = vec![
release("v0.4.11", false, &["app.AppImage"]),
release("v0.4.13", false, &["app.AppImage"]),
release("v0.4.12", false, &["app.AppImage"]),
];
let best = pick_update(&releases, (0, 4, 10), LINUX_EXTENSIONS, false).unwrap();
assert_eq!(best.tag_name, "v0.4.13");
}
// ── is_preview_build (>= instead of >) ─────────────────────────────────
/// The exact scenario triple-c#32 was filed to fix: a preview compiled as
/// `0.4.12-preview.<sha>` (bare `CARGO_PKG_VERSION` "0.4.12") must be
/// offered the `v0.4.12` release that follows it, even though the two
/// compute to the identical numeric tuple.
#[test]
fn a_preview_build_is_offered_the_release_it_precedes() {
let releases = vec![release("v0.4.12", false, &["app.AppImage"])];
assert!(pick_update(&releases, (0, 4, 12), LINUX_EXTENSIONS, false).is_none());
let best = pick_update(&releases, (0, 4, 12), LINUX_EXTENSIONS, true).unwrap();
assert_eq!(best.tag_name, "v0.4.12");
}
#[test]
fn a_preview_build_is_not_offered_an_older_release() {
let releases = vec![release("v0.4.11", false, &["app.AppImage"])];
assert!(pick_update(&releases, (0, 4, 12), LINUX_EXTENSIONS, true).is_none());
}
#[test]
fn a_production_build_still_requires_strictly_newer() {
// A production build must never treat "equal" as an update — that
// would perpetually re-offer the version already running.
let releases = vec![release("v0.4.12", false, &["app.AppImage"])];
assert!(pick_update(&releases, (0, 4, 12), LINUX_EXTENSIONS, false).is_none());
}
}
/// Check whether a newer container image is available in the registry.
///
/// Compares the local image digest with the remote registry digest using the
+111 -16
View File
@@ -1935,7 +1935,7 @@ pub async fn remove_container(container_id: &str) -> Result<(), String> {
"Removing container {} (v=false: named volumes such as claude config are preserved)",
container_id
);
docker
match docker
.remove_container(
container_id,
Some(RemoveContainerOptions {
@@ -1945,7 +1945,17 @@ pub async fn remove_container(container_id: &str) -> Result<(), String> {
}),
)
.await
.map_err(|e| format!("Failed to remove container: {}", e))
{
Ok(()) => Ok(()),
// Already gone is the outcome this call wants, not a failure — a
// caller retrying a leftover from a previous, partially-failed removal
// (see `remove_project`) must not be told it failed forever just
// because a *different* attempt already succeeded.
Err(bollard::errors::Error::DockerResponseServerError {
status_code: 404, ..
}) => Ok(()),
Err(e) => Err(format!("Failed to remove container: {}", e)),
}
}
/// Return the snapshot image name for a project.
@@ -3496,13 +3506,27 @@ async fn rewrite_image_without_secrets(
}
/// Remove the snapshot image for a project (used on Reset / project removal).
///
/// A project that never started never built a snapshot, so "no such image" is
/// the ordinary case, not a failure — it is treated the same as success and
/// logged at most at `info`. A real failure (the image is in use, a
/// permission error, the daemon dropped the connection) is the one thing this
/// returns `Err` for, and callers must not throw that away: see the
/// `remove_project` doc comment on `ProjectRemovalReport` for why an
/// unreported failure here used to make the resource unreachable forever.
pub async fn remove_snapshot_image(project: &Project) -> Result<(), String> {
let docker = get_docker()?;
let image_name = get_snapshot_image_name(project);
remove_image_by_name(&get_snapshot_image_name(project)).await
}
docker
/// Remove a Docker image by name/tag, treating "does not exist" as success.
/// Shared by [`remove_snapshot_image`] and the pending-cleanup retry, which
/// only has the image name (the project record is already gone by then).
pub async fn remove_image_by_name(image_name: &str) -> Result<(), String> {
let docker = get_docker()?;
match docker
.remove_image(
&image_name,
image_name,
Some(RemoveImageOptions {
force: true,
noprune: false,
@@ -3510,25 +3534,91 @@ pub async fn remove_snapshot_image(project: &Project) -> Result<(), String> {
None,
)
.await
.map_err(|e| format!("Failed to remove snapshot image {}: {}", image_name, e))?;
{
Ok(_) => {
log::info!("Removed snapshot image {}", image_name);
Ok(())
}
Err(bollard::errors::Error::DockerResponseServerError {
status_code: 404, ..
}) => Ok(()),
Err(e) => Err(format!("Failed to remove snapshot image {}: {}", image_name, e)),
}
}
/// Remove both named volumes for a project (used on Reset / project removal).
pub async fn remove_project_volumes(project: &Project) -> Result<(), String> {
let docker = get_docker()?;
for vol in [
///
/// Returns the names of volumes that still exist afterwards — empty means
/// both are gone (removed here, or never created). This used to always
/// return `Ok(())` regardless of what actually happened, which made the
/// `if let Err(e)` at every call site unreachable by construction; see
/// triple-c#31. A volume Docker reports as simply not existing is not a
/// leftover and is not included.
pub async fn remove_project_volumes(project: &Project) -> Vec<String> {
remove_volumes_by_name(&[
home_volume_name(&project.id),
config_volume_name(&project.id),
] {
match docker.remove_volume(&vol, None).await {
])
.await
}
/// Remove a set of named volumes, treating "does not exist" as success.
/// Returns the names that still exist afterwards — empty means every one is
/// gone (removed here, or never created).
///
/// Shared by [`remove_project_volumes`] and the pending-cleanup retry, the
/// latter calling this with whatever the former could not remove the first
/// time. Used to always report success regardless of what actually happened,
/// which made every `if let Err(e)` at its call sites unreachable by
/// construction; see triple-c#31.
pub async fn remove_volumes_by_name(names: &[String]) -> Vec<String> {
let docker = match get_docker() {
Ok(d) => d,
Err(e) => {
// Can't reach the daemon to even try, so nothing here can be
// confirmed removed. Reporting all as leftover is the safe
// direction: worst case a later retry finds them already gone.
log::warn!("Could not remove volumes {:?}: {}", names, e);
return names.to_vec();
}
};
let mut leftover = Vec::new();
for vol in names {
match remove_one_volume_with_retry(&docker, vol).await {
Ok(_) => log::info!("Removed volume {}", vol),
Err(e) => log::warn!("Failed to remove volume {} (may not exist): {}", vol, e),
Err(bollard::errors::Error::DockerResponseServerError {
status_code: 404, ..
}) => {}
Err(e) => {
log::warn!("Failed to remove volume {}: {}", vol, e);
leftover.push(vol.clone());
}
}
Ok(())
}
leftover
}
/// Remove one volume, retrying once after a short delay on a 409 ("volume is
/// in use"). Docker releasing a volume's mount reference after the container
/// using it is removed is not always instantaneous, so the very first call
/// site of this — `remove_project`, whose container removal lands
/// immediately before its volume removal — could otherwise turn an ordinary
/// race into a permanent pending-cleanup record and an alarming toast for
/// something that would have cleared itself half a second later.
async fn remove_one_volume_with_retry(
docker: &bollard::Docker,
name: &str,
) -> Result<(), bollard::errors::Error> {
match docker.remove_volume(name, None).await {
Err(bollard::errors::Error::DockerResponseServerError {
status_code: 409, ..
}) => {
tokio::time::sleep(std::time::Duration::from_millis(500)).await;
docker.remove_volume(name, None).await
}
other => other,
}
}
/// Check whether the existing container's configuration still matches the
@@ -4177,7 +4267,12 @@ mod tests {
// It goes into `triple-c.custom-env-fingerprint`, which `docker inspect`
// hands to anything on the host, `docker commit` copies onto the
// project's snapshot image, and the recreation check logs on a mismatch.
let secret = "33da01c1b320644920c20d6b5e0a1c6b3c3451c2";
// **Never a real credential.** This literal was the maintainer's actual
// Gitea token for fourteen days and ninety-two commits, on a public
// mirror — in a test whose whole subject is that secrets do not escape.
// A fixture only has to be *a value*; it never has to be a live one, so
// there is no version of this that justifies pasting something real.
let secret = "not-a-real-token-0000000000000000000000";
let fp = compute_env_fingerprint(&[EnvVar {
key: "TEA_TOKEN".to_string(),
value: secret.to_string(),
+78 -9
View File
@@ -330,29 +330,58 @@ impl ExecSessionManager {
/// meant a moment earlier.
pub const MAX_DROP_BYTES: u64 = 256 * 1024 * 1024;
/// Upload a host file into the container's `/tmp` under `dest_name`. The file is
/// Upload a host file into `dest_dir` under `dest_name`. The file is
/// read and packed into the tar inside a blocking task, so the synchronous IO
/// runs off the async worker. The tar's declared entry size is taken from the
/// bytes actually read (not a separate `stat`), so a file changing size between
/// a size check and the read can't desync the header and corrupt the archive.
/// Returns the in-container path (`/tmp/<dest_name>`).
/// Returns the in-container path (`<dest_dir>/<dest_name>`).
///
/// `dest_dir` must already exist and must already have been checked by the
/// caller — Docker's archive extractor writes wherever it is pointed. The two
/// callers both do that first, by different routes because they are answering
/// different questions: the terminal drop stages into a fixed `/tmp` path it
/// creates itself, and the Files pane passes the directory the user is looking
/// at, which `file_commands::resolve_container_dir` has already confirmed
/// resolves inside `CONTAINER_WRITE_ROOTS`.
pub async fn upload_host_file_to_container(
container_id: &str,
host_path: &str,
dest_dir: &str,
dest_name: &str,
) -> Result<String, String> {
let ids = container_user_ids(container_id).await;
upload_host_file_with_ids(container_id, host_path, dest_dir, dest_name, ids).await
}
/// [`upload_host_file_to_container`] for a caller that already knows the
/// container user's ids.
///
/// `container_user_ids` is a `docker exec`, and the Files pane's upload is a
/// *selection* — one dialog can hand back twenty files. Resolving the ids per
/// file made twenty extra round trips to answer the same `id -u` twenty times,
/// which is seconds of latency for a fact that cannot change inside one
/// container's lifetime. So the loop resolves once and passes the answer in.
/// The wrapper above keeps the single-file callers unchanged.
pub async fn upload_host_file_with_ids(
container_id: &str,
host_path: &str,
dest_dir: &str,
dest_name: &str,
(uid, gid): (u64, u64),
) -> Result<String, String> {
let host_path = host_path.to_string();
let dest_name = dest_name.to_string();
let dest_for_blk = dest_name.clone();
let (uid, gid) = container_user_ids(container_id).await;
let mtime = now_epoch_secs();
let tar_buf = tokio::task::spawn_blocking(move || -> Result<Vec<u8>, String> {
// The caller resolved this path (`resolve_host_read_path`); opening it
// is a second trip through the same directories, so the descriptor is
// checked against the path that was validated before its bytes are
// packed into anything. This is the terminal's drop target, and it is
// the only path by which host bytes enter a container.
// packed into anything. Two paths reach here: the terminal's drop
// target, and the Files pane's upload via `upload_host_file_with_ids`.
// Between them they are how host bytes enter a container.
let file = std::fs::File::open(&host_path)
.map_err(|e| format!("Failed to read {}: {}", host_path, e))?;
crate::commands::file_commands::verify_opened_path(
@@ -381,7 +410,7 @@ pub async fn upload_host_file_to_container(
.upload_to_container(
container_id,
Some(UploadToContainerOptions {
path: "/tmp".to_string(),
path: dest_dir.to_string(),
..Default::default()
}),
tar_buf.into(),
@@ -389,7 +418,17 @@ pub async fn upload_host_file_to_container(
.await
.map_err(|e| format!("Failed to upload file to container: {}", e))?;
Ok(format!("/tmp/{}", dest_name))
Ok(container_join(dest_dir, &dest_name))
}
/// Join a container directory to a name that may itself carry separators.
///
/// Only the *reported* path — the bytes have already landed by the time this is
/// called — but that path is what the terminal echoes and what the Files pane
/// puts in its toast, so `/tmp//x` reading back as a different file than `/tmp/x`
/// is worth the four lines. `"/"` trims to `""` and yields `/x`.
fn container_join(dir: &str, name: &str) -> String {
format!("{}/{}", dir.trim_end_matches('/'), name.trim_start_matches('/'))
}
/// Write `data` into the container at `<dest_dir>/<file_name>` with `mode`.
@@ -779,8 +818,17 @@ pub async fn wait_for_exec_exit(exec_id: &str) -> Option<i64> {
match docker.inspect_exec(exec_id).await {
Ok(info) => {
if info.running != Some(true) {
// Finished: use the reported code (default 0 if somehow absent).
return Some(info.exit_code.unwrap_or(0));
// Finished. `exit_code` rather than `unwrap_or(0)`: an exec
// that has stopped without a reported code is a status
// nobody can vouch for, and flattening it to *success* is
// the wrong default when a caller is deciding whether to
// rename a downloaded file over the user's own.
// `download_container_file` treats `None` as a failure
// precisely because it cannot tell that silence from a
// clean exit; an `unwrap_or` here made that check
// unreachable. Callers that only care about "did it fail
// loudly" use `is_some_and`, which reads `None` as before.
return info.exit_code;
}
}
Err(_) => return None,
@@ -892,4 +940,25 @@ mod tests {
// …but still comfortably above a genuine /proc/net/tcp{,6} pair.
assert!(PROC_NET_OUTPUT_LIMIT > 100 * 150);
}
/// The reported path, which is what the terminal echoes back to Claude and
/// what the Files pane puts in its log line. `/tmp//x` and `/tmp/x` are the
/// same file to the kernel and different strings to a person reading either
/// of those.
#[test]
fn container_join_produces_one_separator() {
assert_eq!(container_join("/tmp", "a.txt"), "/tmp/a.txt");
// The terminal's drop passes a nested name; it must not gain a second
// slash at the seam.
assert_eq!(
container_join("/tmp", "triple-c-drops/a.txt"),
"/tmp/triple-c-drops/a.txt"
);
// A directory the user navigated to can carry a trailing slash, and the
// container root is the case where trimming it must not eat the only
// separator there is.
assert_eq!(container_join("/workspace/", "a.txt"), "/workspace/a.txt");
assert_eq!(container_join("/", "a.txt"), "/a.txt");
assert_eq!(container_join("/", "/a.txt"), "/a.txt");
}
}
+12
View File
@@ -250,6 +250,7 @@ pub fn run() {
// an image open and the sweep will not force; pins are untagged
// second so the images they were holding are dangling by the time
// the sweep lists them; the sweep runs last and collects both.
let projects_store_for_cleanup = projects_store_setup.clone();
tauri::async_runtime::spawn(async move {
crate::docker::reap_probe_containers().await;
let reaped = crate::docker::reap_stale_migration_pins().await;
@@ -257,6 +258,15 @@ pub fn run() {
log::info!("Startup housekeeping dropped {} stale rollback pin(s)", reaped);
}
crate::docker::sweep_orphaned_snapshots_logged("startup").await;
// A container/image/volume `remove_project` could not delete
// is recorded rather than lost — see triple-c#31 — and this is
// the only place anything ever retries it. Takes the store so
// it can refuse to touch a project that turns out to still be
// live — see the long comment on the function itself.
crate::commands::project_commands::retry_pending_cleanup_logged(
&projects_store_for_cleanup,
)
.await;
});
// Auto-start web terminal server if enabled in settings
@@ -497,6 +507,8 @@ pub fn run() {
// Files
commands::file_commands::list_container_files,
commands::file_commands::download_container_backup,
commands::file_commands::download_container_file,
commands::file_commands::upload_files_to_container,
commands::file_commands::read_container_file,
commands::file_commands::rename_container_path,
commands::file_commands::create_container_directory,
+48
View File
@@ -1,6 +1,54 @@
// Prevents additional console window on Windows in release
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]
/// WebKitGTK's DMA-BUF renderer (its default accelerated-compositing path
/// since 2.42) fails outright on some Mesa/driver/compositor combinations
/// under Wayland, printing `Could not create default EGL display:
/// EGL_BAD_PARAMETER. Aborting.` straight to stderr from WebKitGTK's own C
/// code and killing the webview before Triple-C's own logging even starts —
/// see triple-c#34, reported on CachyOS/Arch with Wayland.
///
/// Set unconditionally on Linux rather than gated on `WAYLAND_DISPLAY`: that
/// variable is exported into an XWayland client's environment too, so a
/// gate on it wouldn't even cleanly separate "Wayland" from "X11" — and
/// there is no reliable heuristic at all for the actual variable that
/// matters, which Mesa/driver/compositor combination is affected. This is
/// the blunt instrument, chosen deliberately because the fallback is a real
/// trade, not a free one: the terminal's `@xterm/addon-webgl` renderer
/// (`TerminalView.tsx`) is the one surface in this app actually asking for
/// GPU compositing, and it degrades to xterm's canvas renderer under this
/// setting — slower on very heavy output, but the addon's own construction
/// is already wrapped in a fallback (`WebGL not available` is a handled
/// case, not a crash), so this is a real but graceful downgrade, traded
/// against a startup abort that has no fallback at all.
///
/// Must be set before `triple_c_lib::run()` — GTK/WebKitGTK reads it at
/// their own init time, which happens inside the Tauri builder that
/// function calls into, not at binary load.
///
/// A user who has already set this themselves is left alone. That includes
/// setting it to `0`, on the assumption WebKitGTK treats it as a boolean
/// rather than presence-only — not verified against WebKitGTK's own source,
/// so if it turns out to be presence-only, `=0` still reads as "set" here
/// and disables DMA-BUF the same as any other value, which is at least the
/// safe direction to be wrong in.
///
/// This env var also leaks to whatever the app spawns afterwards — notably
/// a cold-launched default browser via the `opener` plugin's `xdg-open`
/// call. Narrow in practice (an already-running browser just receives the
/// URL; most non-WebKitGTK browsers ignore the variable entirely), but
/// worth knowing before chasing the "links don't open" half of triple-c#34
/// as a separate, unrelated cause.
#[cfg(target_os = "linux")]
fn apply_webkit_wayland_workaround() {
if std::env::var_os("WEBKIT_DISABLE_DMABUF_RENDERER").is_none() {
std::env::set_var("WEBKIT_DISABLE_DMABUF_RENDERER", "1");
}
}
fn main() {
#[cfg(target_os = "linux")]
apply_webkit_wayland_workaround();
triple_c_lib::run()
}
+74
View File
@@ -422,6 +422,61 @@ pub enum ProjectStatus {
Error,
}
/// What `remove_project` could not delete, named so the UI can say so instead
/// of reporting a clean removal that was not one.
///
/// The project record is dropped from `projects.json` regardless — see the
/// long comment on `remove_project` for why refusing is not the answer — but
/// anything named here is also written to a pending-cleanup record that
/// startup housekeeping retries, so it stays reachable after the project it
/// belonged to no longer exists.
#[derive(Debug, Default, Clone, Serialize, Deserialize)]
pub struct ProjectRemovalReport {
/// The project's container, if it could not be removed. Named by its
/// deterministic `triple-c-{id}` name (see `Project::container_name`),
/// not the container id, since the id can be stale or absent and the
/// name is what a later retry can still resolve.
pub container: Option<String>,
/// The `triple-c-snapshot-{id}` image, if it could not be removed.
pub image: Option<String>,
/// Named volumes (home, claude config) that could not be removed.
pub volumes: Vec<String>,
/// True once the leftovers above were durably recorded for automatic
/// retry on the next launch. False means the pending-cleanup record
/// itself could not be written — nothing will retry these, and the UI
/// must say so rather than promising a retry that will not happen.
/// Meaningless (and left at its default) when `is_clean()` is true.
pub retry_scheduled: bool,
}
impl ProjectRemovalReport {
/// True when nothing was left behind.
pub fn is_clean(&self) -> bool {
self.container.is_none() && self.image.is_none() && self.volumes.is_empty()
}
}
/// What `rebuild_project_container` (Reset) produced: the project as it
/// stands after restarting, and anything Reset could not clear.
///
/// Reset's contract is "back to a clean base image", so a leftover volume or
/// image here is reused/rebuilt-from as-is by the container this creates —
/// the opposite of what was asked for — and unlike [`ProjectRemovalReport`]
/// there is no pending-cleanup record for either: the project id survives
/// Reset, so a later Reset attempt can retry them itself.
#[derive(Debug, Clone, Serialize)]
pub struct ProjectResetOutcome {
pub project: Project,
/// The `triple-c-snapshot-{id}` image, if Reset could not remove it. The
/// more serious of the two leftovers here: the new container is created
/// from this image whenever it exists, so a surviving image means Reset
/// silently rebuilt the exact system layer it was asked to discard.
pub leftover_image: Option<String>,
/// Volumes that survived Reset and were mounted into the new container
/// unchanged.
pub leftover_volumes: Vec<String>,
}
/// Which AI model backend/provider the project uses.
/// - `Anthropic`: Direct Anthropic API (user runs `claude login` inside the container)
/// - `Bedrock`: AWS Bedrock with per-project AWS credentials
@@ -650,6 +705,25 @@ impl Project {
mod tests {
use super::*;
// ── ProjectRemovalReport ────────────────────────────────────────────────
#[test]
fn a_report_is_clean_only_with_nothing_left_behind() {
assert!(ProjectRemovalReport::default().is_clean());
let mut r = ProjectRemovalReport::default();
r.container = Some("abc123".to_string());
assert!(!r.is_clean(), "a leftover container must not read as clean");
let mut r = ProjectRemovalReport::default();
r.image = Some("triple-c-snapshot-x:latest".to_string());
assert!(!r.is_clean(), "a leftover image must not read as clean");
let mut r = ProjectRemovalReport::default();
r.volumes.push("triple-c-home-x".to_string());
assert!(!r.is_clean(), "a leftover volume must not read as clean");
}
// ── Custom environment variable names ─────────────────────────────────
#[test]
+18
View File
@@ -26,6 +26,24 @@ pub struct GitHubRelease {
pub body: String,
pub assets: Vec<GitHubAsset>,
pub published_at: String,
/// Whether GitHub itself has this release marked as a prerelease.
/// `#[serde(default)]` rather than required: every response GitHub sends
/// carries this, but nothing here should refuse to parse the rest of a
/// release over one missing field. Defaults to `false` (offered) rather
/// than `true` (excluded) — a missing field only happens if GitHub's API
/// shape changes, and "API changed, therefore updates silently stop
/// working forever" is the worse failure of the two.
///
/// `build-app.yml`'s own mirror never publishes a prerelease, but
/// `.gitea/workflows/backfill-releases.yml` forwards every Gitea release
/// unfiltered, `prerelease` included. A preview release's `preview-<sha>`
/// tag already fails semver parsing on its own, so this field is not what
/// stops *that* case — it is what stops the case tag-parsing can't catch:
/// a normally-tagged release (`v0.4.13`) that someone marks as a
/// prerelease on Gitea (a hotfix candidate, an RC) and a backfill then
/// mirrors as-is. Real defence for that case, not a no-op.
#[serde(default)]
pub prerelease: bool,
}
/// GitHub API asset response (internal).
+1
View File
@@ -1,4 +1,5 @@
pub mod migration_store;
pub mod pending_cleanup;
pub mod projects_store;
pub mod secure;
pub mod settings_store;
@@ -0,0 +1,349 @@
//! Host-side record of Docker resources `remove_project` could not delete.
//!
//! `remove_project` drops a project's id from `projects.json` unconditionally
//! — see the comment on `ProjectRemovalReport` — so once that happens nothing
//! in the app can name the leftover container, image or volume again by any
//! path a user can reach. This is what keeps it reachable anyway: one JSON
//! file per affected project under `<data_dir>/triple-c/pending-cleanup/`,
//! written *before* the project record is dropped. Startup housekeeping
//! retries every record on the next launch (see
//! `commands::project_commands::retry_pending_cleanup_logged`) and deletes
//! the ones that fully succeed.
//!
//! **This record is written in the same instant its record in `projects.json`
//! is destroyed, and it is the only remaining handle on the leftover
//! resource** — which is a stronger claim on durability than an ordinary
//! write-temp-then-rename gives. `storage::migration_store::save` carries the
//! same reasoning for the migration state file: `fs::write` returns once the
//! bytes are in the page cache, and a rename over them is atomic with respect
//! to other readers, not to power loss. A crash in that window leaves the
//! rename applied and the data half-written, which [`list`] then treats as
//! unparseable and skips — reproducing the exact bug this module exists to
//! close, silently, with only a startup log line as evidence. So `save` here
//! takes the same `File::create` → `write_all` → `sync_all` → `rename` →
//! directory-sync shape `migration_store` does.
use std::fs;
use std::path::{Path, PathBuf};
use serde::{Deserialize, Serialize};
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct PendingCleanup {
pub project_id: String,
/// Kept only so a log line or a future UI can name the project without a
/// second lookup — the project record itself is already gone by the time
/// this is read back.
pub project_name: String,
/// The project's container, if it could not be removed. Named by its
/// deterministic `triple-c-{id}` name rather than the (possibly stale)
/// container id Docker handed out — Docker's remove-container API
/// accepts either, and the name is the one identifier guaranteed to still
/// resolve to the same container by the time a retry runs.
pub container_id: Option<String>,
pub image: Option<String>,
pub volumes: Vec<String>,
pub recorded_at: String,
}
impl PendingCleanup {
/// True once nothing named here still needs to be removed.
pub fn is_empty(&self) -> bool {
self.container_id.is_none() && self.image.is_none() && self.volumes.is_empty()
}
}
/// `<data_dir>/triple-c/pending-cleanup`, created on demand.
fn dir() -> Result<PathBuf, String> {
let dir = dirs::data_dir()
.ok_or_else(|| {
"Could not determine data directory. Set XDG_DATA_HOME on Linux.".to_string()
})?
.join("triple-c")
.join("pending-cleanup");
fs::create_dir_all(&dir)
.map_err(|e| format!("Failed to create pending-cleanup directory: {}", e))?;
Ok(dir)
}
/// Project ids are UUIDs, but they arrive over IPC, so refuse to let one steer
/// the write anywhere but the pending-cleanup directory. Mirrors
/// `storage::migration_store::sanitize`.
fn sanitize(project_id: &str) -> String {
project_id
.chars()
.map(|c| if c.is_ascii_alphanumeric() || c == '-' || c == '_' { c } else { '_' })
.collect()
}
/// Write (or overwrite) a project's pending-cleanup record.
pub fn save(record: &PendingCleanup) -> Result<(), String> {
save_in(&dir()?, record)
}
/// Remove a project's pending-cleanup record. Missing is success — this is
/// how a fully-succeeded retry (or a record that never existed) is expressed.
pub fn clear(project_id: &str) -> Result<(), String> {
clear_in(&dir()?, project_id)
}
/// Every pending-cleanup record on disk. An unparseable file is logged and
/// skipped rather than blocking every other project's retry — the same
/// "one bad record can't wedge the rest" reasoning as the migration store.
pub fn list() -> Vec<PendingCleanup> {
let Ok(dir) = dir() else { return Vec::new() };
list_in(&dir)
}
fn path_in(dir: &Path, project_id: &str) -> PathBuf {
dir.join(format!("{}.json", sanitize(project_id)))
}
/// Durable write: fsync the file before the rename, and fsync the directory
/// after it — see the module doc comment for why a plain
/// write-temp-then-rename is not enough here. Mirrors
/// `storage::migration_store::save`/`sync_dir`.
fn save_in(dir: &Path, record: &PendingCleanup) -> Result<(), String> {
let path = path_in(dir, &record.project_id);
let data = serde_json::to_string_pretty(record)
.map_err(|e| format!("Failed to serialize pending cleanup record: {}", e))?;
let tmp = path.with_extension("json.tmp");
{
use std::io::Write;
let mut file = fs::File::create(&tmp)
.map_err(|e| format!("Failed to write pending cleanup record: {}", e))?;
file.write_all(data.as_bytes())
.map_err(|e| format!("Failed to write pending cleanup record: {}", e))?;
file.sync_all()
.map_err(|e| format!("Failed to flush pending cleanup record to disk: {}", e))?;
}
fs::rename(&tmp, &path)
.map_err(|e| format!("Failed to commit pending cleanup record: {}", e))?;
sync_dir(&path);
Ok(())
}
fn clear_in(dir: &Path, project_id: &str) -> Result<(), String> {
let path = path_in(dir, project_id);
match fs::remove_file(&path) {
Ok(()) => Ok(()),
Err(e) if e.kind() == std::io::ErrorKind::NotFound => Ok(()),
Err(e) => Err(format!("Failed to remove pending cleanup record: {}", e)),
}
}
fn list_in(dir: &Path) -> Vec<PendingCleanup> {
let Ok(entries) = fs::read_dir(dir) else { return Vec::new() };
entries
.flatten()
.filter(|e| e.path().extension().is_some_and(|ext| ext == "json"))
.filter_map(|e| {
let path = e.path();
let data = fs::read_to_string(&path).ok()?;
match serde_json::from_str::<PendingCleanup>(&data) {
Ok(record) => Some(record),
Err(err) => {
// Moved aside rather than left in place: a record nothing
// ever repairs would otherwise warn on every single
// startup forever, same as an ordinary `.json` file it
// would keep looking like one to `list_in` on the next
// call too. One aside-copy is enough here — this only
// ever holds names to retry removing, not the class of
// once-in-a-lifetime crash evidence `migration_store`
// keeps multiple timestamped backups of.
let corrupt = path.with_extension("json.corrupt");
let moved = !corrupt.exists() && fs::rename(&path, &corrupt).is_ok();
log::warn!(
"Could not parse pending cleanup record {}: {}{}",
path.display(),
err,
if moved {
format!(" — moved aside to {}", corrupt.display())
} else {
" — leaving it in place".to_string()
}
);
None
}
}
})
.collect()
}
/// fsync the directory holding `path`, so a rename into it survives power
/// loss. Best effort only on the platforms where it is meaningless: Windows
/// has no directory handle to sync and errors on the attempt, so failure is
/// logged rather than propagated — the file's own `sync_all` above is what
/// carries the data. Mirrors `storage::migration_store::sync_dir`, which is
/// private to that module, so this is a small deliberate duplicate rather
/// than a shared dependency between two otherwise-independent stores.
fn sync_dir(path: &Path) {
let Some(dir) = path.parent() else { return };
match fs::File::open(dir).and_then(|d| d.sync_all()) {
Ok(()) => {}
Err(e) => log::debug!(
"Could not fsync the pending-cleanup directory {}: {} — the record itself was flushed",
dir.display(),
e
),
}
}
#[cfg(test)]
mod tests {
use super::*;
fn temp_dir(name: &str) -> PathBuf {
let dir = std::env::temp_dir().join(format!(
"triple-c-pending-cleanup-{}-{}",
name,
uuid::Uuid::new_v4().simple()
));
fs::create_dir_all(&dir).unwrap();
dir
}
fn record(project_id: &str) -> PendingCleanup {
PendingCleanup {
project_id: project_id.to_string(),
project_name: "Some Project".to_string(),
container_id: Some("triple-c-abc".to_string()),
image: Some("triple-c-snapshot-abc:latest".to_string()),
volumes: vec!["triple-c-home-abc".to_string()],
recorded_at: "2026-08-25T00:00:00Z".to_string(),
}
}
#[test]
fn project_ids_cannot_escape_the_pending_cleanup_directory() {
assert_eq!(sanitize("../../etc/passwd"), "______etc_passwd");
assert_eq!(sanitize("a/b"), "a_b");
assert_eq!(
sanitize("ab62cd24-51aa-4645-8f5c-17a124062050"),
"ab62cd24-51aa-4645-8f5c-17a124062050"
);
}
#[test]
fn is_empty_reflects_whatever_still_needs_removing() {
let mut r = record("p1");
assert!(!r.is_empty());
r.container_id = None;
r.image = None;
assert!(!r.is_empty(), "a leftover volume alone still counts");
r.volumes.clear();
assert!(r.is_empty());
}
/// Exercises the real `save_in`/`list_in`/`clear_in` — not a
/// re-implementation of their bodies — against a temp directory standing
/// in for `dir()`.
#[test]
fn a_saved_record_round_trips_and_clearing_removes_it() {
let dir = temp_dir("roundtrip");
let rec = record("proj-1");
save_in(&dir, &rec).expect("save");
let found = list_in(&dir);
assert_eq!(found.len(), 1);
assert_eq!(found[0].project_id, "proj-1");
assert_eq!(found[0].volumes, vec!["triple-c-home-abc".to_string()]);
clear_in(&dir, "proj-1").expect("clear");
assert!(list_in(&dir).is_empty());
fs::remove_dir_all(&dir).ok();
}
/// A second `save` for the same project overwrites rather than appending
/// — a retry that narrows the leftovers must not leave the old, wider
/// record behind it.
#[test]
fn saving_the_same_project_twice_overwrites_not_appends() {
let dir = temp_dir("overwrite");
let mut rec = record("proj-1");
save_in(&dir, &rec).expect("save");
rec.container_id = None;
rec.image = None;
save_in(&dir, &rec).expect("save again");
let found = list_in(&dir);
assert_eq!(found.len(), 1, "one file per project, not one per save");
assert!(found[0].container_id.is_none());
assert_eq!(found[0].volumes, vec!["triple-c-home-abc".to_string()]);
fs::remove_dir_all(&dir).ok();
}
/// A record that fails to parse must not poison the rest of the listing.
#[test]
fn an_unparseable_record_is_skipped_not_fatal() {
let dir = temp_dir("corrupt");
fs::write(dir.join("bad.json"), "{ not json").unwrap();
save_in(&dir, &record("proj-2")).expect("save");
let found = list_in(&dir);
assert_eq!(found.len(), 1);
assert_eq!(found[0].project_id, "proj-2");
fs::remove_dir_all(&dir).ok();
}
/// A record that fails to parse is moved aside once, rather than left in
/// place to be re-warned about — and re-warned about — on every future
/// launch forever.
#[test]
fn an_unparseable_record_is_moved_aside_exactly_once() {
let dir = temp_dir("corrupt-aside");
let bad = dir.join("bad.json");
fs::write(&bad, "{ not json").unwrap();
list_in(&dir);
assert!(!bad.exists(), "the bad file should have been moved aside");
let corrupt = dir.join("bad.json.corrupt");
assert!(corrupt.exists(), "and the moved copy should be at .json.corrupt");
// A second pass must not warn about `bad.json` again — it is gone —
// and must not choke on `.json.corrupt` already being there.
assert!(list_in(&dir).is_empty());
assert!(corrupt.exists(), "the aside copy is not itself deleted");
fs::remove_dir_all(&dir).ok();
}
/// `list_in` must not pick up the `.json.tmp` staging file `save_in`
/// leaves behind if a crash lands between the write and the rename — the
/// whole point of the temp-then-rename dance is that only the renamed
/// file is ever a complete record.
#[test]
fn a_leftover_tmp_file_is_not_listed() {
let dir = temp_dir("tmp-leftover");
fs::write(dir.join("proj-3.json.tmp"), "not a complete record").unwrap();
assert!(list_in(&dir).is_empty());
fs::remove_dir_all(&dir).ok();
}
/// Clearing by project id must remove exactly the file that id maps to
/// under `sanitize`, and nothing else.
#[test]
fn clearing_one_project_does_not_touch_another() {
let dir = temp_dir("clear-scoped");
save_in(&dir, &record("proj-a")).unwrap();
save_in(&dir, &record("proj-b")).unwrap();
clear_in(&dir, "proj-a").unwrap();
let found = list_in(&dir);
assert_eq!(found.len(), 1);
assert_eq!(found[0].project_id, "proj-b");
fs::remove_dir_all(&dir).ok();
}
}
+7 -1
View File
@@ -757,7 +757,13 @@
sessionType === 'claude'
) {
sendTerminalInput('\x1b\r');
return false; // xterm must not also send a bare CR, which submits
// `preventDefault()` is what stops the submit, not the `return false`.
// xterm's `_keyDown` returns before setting `_keyDownHandled`, so
// `_keyPress` still fires and emits a bare CR for Enter — inserting the
// newline and then submitting the prompt anyway. See the same comment
// in TerminalView.tsx.
e.preventDefault();
return false;
}
return true;
});
@@ -144,15 +144,16 @@ export default function FileViewerModal({ projectId, entry, onClose }: Props) {
{preview.kind === "too-large" && (
<p className="text-[13px] text-[var(--text-secondary)]">
This file is {formatBytes(entry.size)} — too large to preview in the app. Open it
from a terminal in the container, or take a backup and open it on the host.
This file is {formatBytes(entry.size)} — too large to preview in the app. Use
“Save to host…” on its row to open it in a program that can, or read it from a
terminal in the container.
</p>
)}
{preview.kind === "unsupported" && (
<p className="text-[13px] text-[var(--text-secondary)]">
There is no preview for this file type. Open it from a terminal in the container,
or take a backup and open it on the host.
There is no preview for this file type. Use “Save to host…” on its row to open it
in a program that can, or read it from a terminal in the container.
</p>
)}
@@ -1,5 +1,5 @@
import { describe, it, expect, vi, beforeEach } from "vitest";
import { render, screen, fireEvent, act, waitFor } from "@testing-library/react";
import { render, screen, fireEvent, act, waitFor, within } from "@testing-library/react";
import FilesTab from "./FilesTab";
import type { FileContents, FileEntry, Project } from "../../../lib/types";
@@ -7,6 +7,8 @@ const listContainerFiles = vi.fn();
const renameContainerPath = vi.fn(async () => "");
const createContainerDirectory = vi.fn(async () => "");
const readContainerFile = vi.fn();
const uploadFilesToContainer = vi.fn();
const downloadContainerFile = vi.fn();
vi.mock("../../../lib/tauri-commands", () => ({
listContainerFiles: (p: string, path: string) => listContainerFiles(p, path),
@@ -14,6 +16,8 @@ vi.mock("../../../lib/tauri-commands", () => ({
createContainerDirectory: (p: string, parent: string, n: string) =>
createContainerDirectory(p, parent, n),
readContainerFile: (p: string, path: string, max?: number) => readContainerFile(p, path, max),
uploadFilesToContainer: (p: string, dir: string) => uploadFilesToContainer(p, dir),
downloadContainerFile: (p: string, path: string) => downloadContainerFile(p, path),
}));
/** Transient failures land in `ToastHost`, not in an inline string. */
@@ -175,9 +179,15 @@ describe("FilesTab viewer", () => {
});
expect(await screen.findByText(/too large to preview/)).toBeTruthy();
expect(screen.queryByAltText("huge.png")).toBeNull();
// The way out is named, and it is not a host path this pane could write:
// a terminal inside the container, or a backup.
expect(screen.getByText(/take a backup/)).toBeTruthy();
// A refusal has to name the way out, and the way out is now the button on
// the row rather than the `cat`-it-in-a-terminal workaround that existed
// because the button did not.
// Scoped to the modal: every file row also carries a "Save to host…"
// button now, so an unscoped query matches the grid behind the overlay and
// would pass with the refusal saying nothing at all.
expect(
within(screen.getByRole("dialog")).getByText(/Save to host/),
).toBeTruthy();
});
it("says so in words when only a prefix of a big text file came back", async () => {
@@ -392,3 +402,73 @@ describe("FilesTab grid semantics", () => {
expect(screen.getByRole("alert").textContent).toContain("Permission denied");
});
});
/**
* The pane's two host-transfer affordances.
*
* They are asserted at the *button* level and not only in the hook, because
* this is the half that was actually lost: the commands behind them had been
* deleted, but so had the controls, and a working command nobody can reach is
* the same regression. Neither button names a host path — Rust opens the
* dialog — so what a click is required to prove is that the container-side
* argument reaching the backend is the one the user is looking at.
*/
describe("FilesTab host transfers", () => {
beforeEach(() => {
uploadFilesToContainer.mockResolvedValue({ uploaded: [], failures: [] });
downloadContainerFile.mockResolvedValue(4);
});
it("uploads into the directory currently on screen", async () => {
listContainerFiles.mockResolvedValue([entry("src", { is_directory: true })]);
await renderTab();
await act(async () => {
fireEvent.doubleClick(screen.getByText("src"));
});
uploadFilesToContainer.mockResolvedValueOnce({
uploaded: ["/workspace/src/a.txt"],
failures: [],
});
await act(async () => {
fireEvent.click(screen.getByRole("button", { name: "Upload…" }));
});
expect(uploadFilesToContainer).toHaveBeenCalledWith("p1", "/workspace/src");
});
it("offers Save to host on a file and not on a folder", async () => {
listContainerFiles.mockResolvedValue([
entry("notes.txt"),
entry("src", { is_directory: true }),
]);
await renderTab();
// The accessible name carries the row, per WCAG 2.5.3 — and it is how a
// per-row action is told apart from every other row's copy of it.
expect(
screen.getByRole("button", { name: "Save to host — notes.txt" }),
).toBeTruthy();
expect(
screen.queryByRole("button", { name: "Save to host — src" }),
).toBeNull();
await act(async () => {
fireEvent.click(screen.getByRole("button", { name: "Save to host — notes.txt" }));
});
expect(downloadContainerFile).toHaveBeenCalledWith("p1", "/workspace/notes.txt");
});
it("does not open the file viewer when Save to host is double-clicked", async () => {
// Opening a file is a *double*-click on the row, and a double-click on a
// button inside that row still bubbles — `onClick`'s `stopPropagation` does
// nothing about it. So an impatient double-click on Save used to save the
// file and drop the viewer modal over the pane at the same time, on top of
// the save dialog the backend had just opened.
listContainerFiles.mockResolvedValue([entry("notes.txt")]);
readContainerFile.mockResolvedValue(contents("hello"));
await renderTab();
await act(async () => {
fireEvent.doubleClick(
screen.getByRole("button", { name: "Save to host — notes.txt" }),
);
});
expect(readContainerFile).not.toHaveBeenCalled();
});
});
+62 -7
View File
@@ -15,13 +15,26 @@ const PARENT_ROW = "..";
/**
* The project's file browser.
*
* Container-side only: it lists, opens, renames and creates folders inside the
* container, and it does no host filesystem I/O at all. A file gets *into* a
* container by being dropped onto the Terminal tab, and a whole tree comes back
* out through "Back up container" in the project's Workspace settings. Four
* successive audits found that host paths crossing IPC were where the criticals
* lived; those two paths are the ones that survived, and this pane is not one
* of them.
* It lists, opens, renames and creates folders inside the container, and it
* copies single files across the boundary: "Upload…" in the toolbar, and a
* per-row "Save to host…".
*
* **Neither of those names a host path, and this file must never learn how
* to.** Four successive audits found that host paths crossing IPC were where
* the criticals lived — a frontend `open()`/`save()` handing Rust a string is
* exactly the shape that failed — so the picker is opened by the *backend*
* (`pick_files_to_upload` / `pick_save_path` in `commands/file_commands.rs`).
* What this file *sends* is a project id and a container path; the host side of
* the transfer is chosen by a person in an OS dialog. That is why
* `uploadFiles()` takes no argument and `saveToHost()` takes only the entry.
* (A failed transfer does report a host path back, in the text of its error —
* the inbound direction is the one that is closed, not both.)
*
* Drag-and-drop is deliberately still absent, in both directions. A file also
* gets into a container by being dropped onto the Terminal tab, and a whole
* tree comes back out through "Back up container" in the project's ⋯ menu —
* which is still the right answer for a directory, since "Save to host…" is one
* file at a time and is not offered on folders.
*
* Interaction model, chosen to match every desktop file manager rather than
* the old half-and-half: **single click selects, double click opens**. That
@@ -52,6 +65,10 @@ export default function FilesTab({ project }: Props) {
refresh,
renameEntry,
createFolder,
uploadFiles,
saveToHost,
uploading,
savingPaths,
} = useFileManager(project.id);
const running = project.status === "running";
@@ -305,6 +322,16 @@ export default function FilesTab({ project }: Props) {
>
New folder
</Button>
{/* The file picker this opens belongs to Rust, not to the webview — so
this file imports no dialog plugin and never composes a host path.
`uploadFiles` takes no argument for the same reason. */}
<Button
onClick={() => void uploadFiles()}
disabled={uploading}
className="ml-1"
>
{uploading ? "Uploading…" : "Upload…"}
</Button>
<Button onClick={refresh} disabled={loading} className="ml-1">
Refresh
</Button>
@@ -501,6 +528,34 @@ export default function FilesTab({ project }: Props) {
>
Rename
</Button>
{/* Folders have no single-file equivalent — a
recursive download is what "Back up container" is
for, and offering one here would mean rebuilding
the tree-walking this pane deliberately does not
do. */}
{!entry.is_directory && (
<Button
aria-label={`Save to host — ${entry.name}`}
className="ml-1"
// Only this row: a large file can take a while,
// and there is no reason the rest of the pane
// should go dead while it is written.
disabled={savingPaths.has(entry.path)}
onClick={(e) => {
e.stopPropagation();
void saveToHost(entry);
}}
// A double-click is its own event, and
// `onClick`'s `stopPropagation` says nothing
// about it — so an impatient double-click here
// reached the row's `onDoubleClick` and dropped
// the viewer modal over the pane, on top of the
// save dialog the backend had just opened.
onDoubleClick={(e) => e.stopPropagation()}
>
{savingPaths.has(entry.path) ? "Saving…" : "Save to host…"}
</Button>
)}
</>
)}
</td>
@@ -1,5 +1,6 @@
import { useEffect, useMemo, useState } from "react";
import { useShallow } from "zustand/react/shallow";
import { projectRemovalIsClean } from "../../../lib/types";
import { useAppState } from "../../../store/appState";
import { useProjectActions } from "../../../hooks/useProjectActions";
import { useProjects } from "../../../hooks/useProjects";
@@ -18,6 +19,7 @@ import ConfigTab from "./ConfigTab";
import FilesTab from "./FilesTab";
import BrowserTab from "./BrowserTab";
import { formatUptime } from "./format";
import { describeLeftovers, leftoverPronoun, leftoverVerb } from "./removalReport";
const TABS = [
{ id: "overview", label: "Overview" },
@@ -282,7 +284,25 @@ export default function ProjectHome({ projectId, active }: Props) {
onConfirm={async () => {
setConfirmRemove(false);
try {
await remove(project.id);
const report = await remove(project.id);
if (!projectRemovalIsClean(report)) {
const verb = leftoverVerb(report);
if (report.retry_scheduled) {
useAppState.getState().pushToast({
kind: "info",
message: `“${project.name}” was removed, but Triple-C could not confirm all its Docker resources were removed`,
detail: `Triple-C could not confirm ${describeLeftovers(report)} ${verb} removed. It will check again the next time it starts.`,
});
} else {
// The pending-cleanup record itself failed to save — no
// retry will happen, so this must not promise one.
useAppState.getState().pushToast({
kind: "error",
message: `“${project.name}” was removed, but Triple-C could not confirm its Docker resources were removed`,
detail: `Triple-C could not confirm ${describeLeftovers(report)} ${verb} removed, and could not record this for a retry. You may need to remove ${leftoverPronoun(report)} manually (\`docker rm\` / \`docker rmi\` / \`docker volume rm\`).`,
});
}
}
} catch (e) {
useAppState.getState().pushToast({
kind: "error",
@@ -0,0 +1,51 @@
import { describe, it, expect } from "vitest";
import { describeLeftovers, leftoverVerb } from "./removalReport";
import { projectRemovalIsClean } from "../../../lib/types";
import type { ProjectRemovalReport } from "../../../lib/types";
function report(overrides: Partial<ProjectRemovalReport> = {}): ProjectRemovalReport {
return {
container: null,
image: null,
volumes: [],
retry_scheduled: false,
...overrides,
};
}
describe("projectRemovalIsClean", () => {
it("is true only when nothing survived", () => {
expect(projectRemovalIsClean(report())).toBe(true);
expect(projectRemovalIsClean(report({ container: "triple-c-abc" }))).toBe(false);
expect(projectRemovalIsClean(report({ image: "triple-c-snapshot-abc:latest" }))).toBe(false);
expect(projectRemovalIsClean(report({ volumes: ["triple-c-home-abc"] }))).toBe(false);
});
});
describe("describeLeftovers", () => {
it("names each kind of leftover", () => {
expect(describeLeftovers(report({ container: "triple-c-abc" }))).toBe("its container");
expect(describeLeftovers(report({ image: "x" }))).toBe("its saved image");
expect(describeLeftovers(report({ volumes: ["v1"] }))).toBe("a volume");
expect(describeLeftovers(report({ volumes: ["v1", "v2"] }))).toBe("2 volumes");
});
it("joins multiple kinds together", () => {
expect(
describeLeftovers(report({ container: "triple-c-abc", image: "x", volumes: ["v1", "v2"] })),
).toBe("its container, its saved image, 2 volumes");
});
});
describe("leftoverVerb", () => {
it("is singular for exactly one leftover of any kind", () => {
expect(leftoverVerb(report({ container: "triple-c-abc" }))).toBe("was");
expect(leftoverVerb(report({ image: "x" }))).toBe("was");
expect(leftoverVerb(report({ volumes: ["v1"] }))).toBe("was");
});
it("is plural once more than one thing survived, including multiple volumes alone", () => {
expect(leftoverVerb(report({ container: "triple-c-abc", image: "x" }))).toBe("were");
expect(leftoverVerb(report({ volumes: ["v1", "v2"] }))).toBe("were");
});
});
@@ -0,0 +1,39 @@
import type { ProjectRemovalReport } from "../../../lib/types";
/**
* Names what a `ProjectRemovalReport` says survived, for the leftover toast.
*
* Worded as "could not confirm" rather than "is still on disk": the same
* report shape covers a genuine leftover (a locked volume) and a daemon that
* was simply unreachable at the time, in which case nothing was ever created
* and there is nothing to find — asserting certainty either way would be
* wrong in one of those cases.
*/
export function describeLeftovers(report: ProjectRemovalReport): string {
const parts: string[] = [];
if (report.container) parts.push("its container");
if (report.image) parts.push("its saved image");
if (report.volumes.length === 1) parts.push("a volume");
else if (report.volumes.length > 1) parts.push(`${report.volumes.length} volumes`);
return parts.join(", ");
}
/** How many distinct things `describeLeftovers` is describing — a container
* and an image each count as one, however many volumes are named. Shared by
* `leftoverVerb` and `leftoverPronoun` so the two can never disagree about
* singular vs. plural. */
function leftoverCount(report: ProjectRemovalReport): number {
return (report.container ? 1 : 0) + (report.image ? 1 : 0) + report.volumes.length;
}
/** Verb agreement for `describeLeftovers`'s output — "its container" needs
* "was", "its container, a volume" needs "were". */
export function leftoverVerb(report: ProjectRemovalReport): "was" | "were" {
return leftoverCount(report) === 1 ? "was" : "were";
}
/** Pronoun agreement for referring back to `describeLeftovers`'s output —
* "remove it manually" for one thing, "remove them manually" for more. */
export function leftoverPronoun(report: ProjectRemovalReport): "it" | "them" {
return leftoverCount(report) === 1 ? "it" : "them";
}
@@ -137,19 +137,36 @@ afterEach(() => {
});
describe("TerminalView — Shift+Enter", () => {
it("sends ESC+CR and nothing else in a Claude session", () => {
it("sends ESC+CR and cancels the keydown, so no bare CR follows", () => {
// **The cancel is the load-bearing half, and this test could not see it.**
//
// Returning `false` from xterm's custom key handler does not cancel the
// event: `_keyDown` returns before setting `_keyDownHandled`, so
// `_keyPress` still runs and emits a bare CR for Enter's charCode 13. In a
// real browser that submitted the prompt straight after inserting the
// newline. jsdom never synthesizes the follow-up keypress, so the old
// `expect(sent()).not.toContain("\r")` assertion below could not fail no
// matter what the code did — it was named for a behaviour it could not
// exercise.
//
// Asserting `defaultPrevented` pins the actual mechanism that stops the
// keypress, which is a property jsdom *can* observe.
const { container } = mountSession("claude");
fireEvent.keyDown(helperTextarea(container), {
const event = new KeyboardEvent("keydown", {
key: "Enter",
keyCode: 13,
shiftKey: true,
bubbles: true,
cancelable: true,
});
helperTextarea(container).dispatchEvent(event);
// The bytes `/terminal-setup` installs for every other editor.
expect(sent()).toEqual(["\x1b\r"]);
// And specifically not the bare CR that would have submitted the prompt.
expect(sent()).not.toContain("\r");
// Without this, the browser fires keypress and xterm submits.
expect(event.defaultPrevented).toBe(true);
});
it("leaves a plain Enter alone", () => {
+13 -1
View File
@@ -414,7 +414,19 @@ export default function TerminalView({ sessionId, active }: Props) {
sessionTypeRef.current === "claude"
) {
sendInput(sessionId, "\x1b\r");
return false; // xterm must not also send a bare CR, which submits
// **`preventDefault()` is what stops the submit, not the `return false`.**
//
// xterm's `_keyDown` returns the instant a custom handler says `false`
// — *before* it sets `_keyDownHandled` and before it cancels the event.
// `_keyPress` then checks that same flag, finds it still false, and
// emits a bare CR for Enter's charCode 13. So returning `false` alone
// sent ESC+CR *and* a submit: the newline was inserted and the
// half-written prompt went to Claude with a stray blank line in it.
// Cancelling the keydown is what stops the browser firing keypress at
// all. Verified in Chromium; jsdom never synthesizes the follow-up
// keypress, which is why the unit test could not see this.
event.preventDefault();
return false;
}
return true;
});
+10 -1
View File
@@ -47,7 +47,16 @@ function ToastCard({ toast, onDismiss }: { toast: Toast; onDismiss: () => void }
{tone.glyph}
</span>
<div className="flex-1 min-w-0">
<div className="text-[var(--text-primary)] break-words">{toast.message}</div>
{/* Clamped. A toast message is normally a sentence, but some of them
quote text a *container* wrote — and this card is `z-[60]`, above
every modal, with its dismiss button at the top. An unclamped
message of a few kilobytes is a card taller than the viewport whose
✕ has been pushed off-screen, i.e. an unclosable overlay. The
`detail` block below has always had `max-h-40 overflow-auto`; this
half did not. */}
<div className="text-[var(--text-primary)] break-words max-h-40 overflow-y-auto">
{toast.message}
</div>
{toast.detail && (
<>
<button
+267
View File
@@ -6,12 +6,16 @@ import type { FileEntry } from "../lib/types";
const listContainerFiles = vi.fn();
const renameContainerPath = vi.fn();
const createContainerDirectory = vi.fn();
const uploadFilesToContainer = vi.fn();
const downloadContainerFile = vi.fn();
vi.mock("../lib/tauri-commands", () => ({
listContainerFiles: (p: string, path: string) => listContainerFiles(p, path),
renameContainerPath: (p: string, f: string, t: string) => renameContainerPath(p, f, t),
createContainerDirectory: (p: string, parent: string, n: string) =>
createContainerDirectory(p, parent, n),
uploadFilesToContainer: (p: string, dir: string) => uploadFilesToContainer(p, dir),
downloadContainerFile: (p: string, path: string) => downloadContainerFile(p, path),
readContainerFile: vi.fn(),
}));
@@ -45,6 +49,8 @@ const file = (name: string, extra: Partial<FileEntry> = {}): FileEntry => ({
beforeEach(() => {
vi.clearAllMocks();
listContainerFiles.mockResolvedValue([file("a.txt")]);
uploadFilesToContainer.mockResolvedValue({ uploaded: [], failures: [] });
downloadContainerFile.mockResolvedValue(0);
});
describe("useFileManager navigation", () => {
@@ -292,3 +298,264 @@ describe("useFileManager surfaces written refusals as prose", () => {
expect(lastToast().detail).toBe("no space left on device");
});
});
/**
* Both of these actions are *dialog-driven from Rust* — the hook passes a
* project and a directory and gets back an answer, and there is deliberately no
* host path anywhere in this file. What is worth pinning is the vocabulary of
* that answer, because two of its values look like failure and are not: `null`
* means the user dismissed the picker, and `0` bytes means an empty file was
* saved successfully.
*/
describe("useFileManager saving to the host", () => {
it("treats a zero-byte save as a success", async () => {
// The bug this exists for: `if (!bytes) return` reads a genuine
// zero-length file — an empty `.gitkeep`, a truncated log — as a
// dismissal, so the file lands on the host and the app says nothing at
// all. The sentinel is `null`, and only `null`.
downloadContainerFile.mockResolvedValueOnce(0);
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.saveToHost(file("empty.txt"));
});
expect(result.current.completed).toContain("empty.txt");
expect(pushToast).not.toHaveBeenCalled();
});
it("says nothing at all when the dialog is dismissed", async () => {
downloadContainerFile.mockResolvedValueOnce(null);
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.saveToHost(file("a.txt"));
});
expect(result.current.completed).toBeNull();
expect(pushToast).not.toHaveBeenCalled();
});
it("names the file in a refusal", async () => {
downloadContainerFile.mockRejectedValueOnce("/etc/shadow is not readable");
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.saveToHost(file("secret.txt"));
});
expect(toastText()).toContain("secret.txt");
});
});
describe("useFileManager uploading from the host", () => {
it("uploads into the directory on screen and shows the result", async () => {
uploadFilesToContainer.mockResolvedValueOnce({
uploaded: ["/workspace/app/one.txt", "/workspace/app/two.txt"],
failures: [],
});
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.navigate("/workspace/app");
});
listContainerFiles.mockClear();
await act(async () => {
await result.current.uploadFiles();
});
expect(uploadFilesToContainer).toHaveBeenCalledWith("p1", "/workspace/app");
expect(result.current.completed).toContain("2 files");
// The directory is named. `target` is captured at click time and the
// picker is a modal dialog, so "Uploaded 2 files." on its own can be shown
// in front of a grid those files are not in.
expect(result.current.completed).toContain("/workspace/app");
// The new files are only on screen if the listing was asked for again.
expect(listContainerFiles).toHaveBeenCalledWith("p1", "/workspace/app");
});
it("reports every file that failed, not just a count", async () => {
// "3 of 5 uploaded" without naming the two is not a report — the user
// cannot tell which ones to retry, or why.
uploadFilesToContainer.mockResolvedValueOnce({
uploaded: ["/workspace/ok.txt"],
failures: [
"/home/j/Pictures is a folder — upload its files individually.",
"/home/j/vm.img is too large to upload (900 MB; limit 256 MB).",
],
});
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.uploadFiles();
});
expect(pushToast).toHaveBeenCalledTimes(2);
expect(toastText()).toContain("is a folder");
expect(toastText()).toContain("too large");
// A partial batch still succeeded partially, and the pane must show it.
expect(result.current.completed).toContain("1 file");
});
it("does not refresh when the picker was dismissed", async () => {
uploadFilesToContainer.mockResolvedValueOnce(null);
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.navigate("/workspace/app");
});
listContainerFiles.mockClear();
await act(async () => {
await result.current.uploadFiles();
});
expect(listContainerFiles).not.toHaveBeenCalled();
expect(pushToast).not.toHaveBeenCalled();
expect(result.current.completed).toBeNull();
});
it("reports a refusal that happened before the picker once, not per file", async () => {
// No container, not running, or a directory this pane may not write to.
// There is no selection yet, so there is nothing to enumerate.
uploadFilesToContainer.mockRejectedValueOnce(
"Start the project before uploading files — it runs inside the running container.",
);
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.uploadFiles();
});
expect(pushToast).toHaveBeenCalledTimes(1);
expect(toastText()).toContain("Start the project");
});
it("does not drag the pane back when the user navigated during the upload", async () => {
// The same rule rename and new-folder follow: a slow operation must not
// relist a directory the user has already left.
let release: (v: unknown) => void = () => {};
uploadFilesToContainer.mockReturnValueOnce(
new Promise((resolve) => {
release = resolve;
}),
);
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.navigate("/workspace/app");
});
let uploading: Promise<void>;
act(() => {
uploading = result.current.uploadFiles();
});
await act(async () => {
await result.current.navigate("/workspace/other");
});
listContainerFiles.mockClear();
await act(async () => {
release({ uploaded: ["/workspace/app/one.txt"], failures: [] });
await uploading;
});
expect(listContainerFiles).not.toHaveBeenCalled();
expect(result.current.currentPath).toBe("/workspace/other");
});
});
describe("useFileManager transfer state", () => {
it("marks an upload in flight for as long as it runs", async () => {
// Without this the button stays live: a second click opens a second OS
// dialog and runs a second concurrent exec, and a slow transfer looks
// exactly like a click that did nothing.
let release: (v: unknown) => void = () => {};
uploadFilesToContainer.mockReturnValueOnce(
new Promise((resolve) => {
release = resolve;
}),
);
const { result } = renderHook(() => useFileManager("p1"));
expect(result.current.uploading).toBe(false);
let uploading: Promise<void>;
act(() => {
uploading = result.current.uploadFiles();
});
expect(result.current.uploading).toBe(true);
await act(async () => {
release({ uploaded: [], failures: [] });
await uploading;
});
expect(result.current.uploading).toBe(false);
});
it("stays in flight through the refresh, not just the transfer", async () => {
// Clearing the flag the moment the command settled put the button back
// while the re-listing was still running, so a second click landed
// mid-refresh on a grid that was still showing the old contents.
uploadFilesToContainer.mockResolvedValueOnce({
uploaded: ["/workspace/a.txt"],
failures: [],
});
let finishListing: (v: unknown) => void = () => {};
listContainerFiles.mockReturnValueOnce(
new Promise((resolve) => {
finishListing = resolve;
}),
);
const { result } = renderHook(() => useFileManager("p1"));
let uploading: Promise<void>;
act(() => {
uploading = result.current.uploadFiles();
});
await act(async () => {
await Promise.resolve();
await Promise.resolve();
});
// The transfer is done; the listing it triggered is not.
expect(result.current.uploading).toBe(true);
await act(async () => {
finishListing([file("a.txt")]);
await uploading;
});
expect(result.current.uploading).toBe(false);
});
it("clears the upload flag when the transfer fails", async () => {
// The `catch` returns early, so without a `finally` the button is disabled
// for the rest of the session — the failure mode is a pane that can never
// upload again, with no error left on screen to explain it.
uploadFilesToContainer.mockRejectedValueOnce("Start the project first");
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.uploadFiles();
});
expect(result.current.uploading).toBe(false);
});
it("tracks each save separately, so one finishing does not free another", async () => {
// The bug this exists for: `savingPath` was a single string. Starting a
// second save overwrote it, so the first row went live again mid-transfer,
// and whichever save settled first cleared the flag for both — dismissing
// the second dialog was enough. A set is what the design needs, because
// "only the row being saved is disabled" is exactly what makes a second
// save startable.
let releaseBig: (v: unknown) => void = () => {};
let releaseSmall: (v: unknown) => void = () => {};
downloadContainerFile
.mockReturnValueOnce(new Promise((r) => { releaseBig = r; }))
.mockReturnValueOnce(new Promise((r) => { releaseSmall = r; }));
const { result } = renderHook(() => useFileManager("p1"));
let big: Promise<void>;
let small: Promise<void>;
act(() => { big = result.current.saveToHost(file("big.bin")); });
expect(result.current.savingPaths.has("/workspace/big.bin")).toBe(true);
act(() => { small = result.current.saveToHost(file("notes.txt")); });
// Both, at once — a scalar could only hold the second.
expect(result.current.savingPaths.has("/workspace/big.bin")).toBe(true);
expect(result.current.savingPaths.has("/workspace/notes.txt")).toBe(true);
// The second one finishing must not re-enable the first, which is still
// streaming. `null` is the dismissal path, which is how this was cheapest
// to trigger in practice.
await act(async () => { releaseSmall(null); await small; });
expect(result.current.savingPaths.has("/workspace/notes.txt")).toBe(false);
expect(result.current.savingPaths.has("/workspace/big.bin")).toBe(true);
await act(async () => { releaseBig(10); await big; });
expect(result.current.savingPaths.size).toBe(0);
});
it("clears a row's saving flag when its save fails", async () => {
downloadContainerFile.mockRejectedValueOnce("Permission denied");
const { result } = renderHook(() => useFileManager("p1"));
await act(async () => {
await result.current.saveToHost(file("b.txt"));
});
expect(result.current.savingPaths.size).toBe(0);
});
});
+110 -2
View File
@@ -3,6 +3,7 @@ import type { FileEntry } from "../lib/types";
import * as commands from "../lib/tauri-commands";
import { useAppState } from "../store/appState";
import { errorText, readableRefusal } from "../lib/refusalText";
import { formatBytes } from "../lib/formatBytes";
/**
* ## Where failures are reported
@@ -13,8 +14,8 @@ import { errorText, readableRefusal } from "../lib/refusalText";
* (empty) grid. It is on screen, it is in context, it explains why there are
* no rows, and it is not transient — it stands until the directory lists.
*
* Every **transient operation** failure — rename, create folder — goes to
* `ToastHost` instead. Those used to land in the same inline `error` div, which
* Every **transient operation** failure — rename, create folder, upload, save
* to host — goes to `ToastHost` instead. Those used to land in the same inline `error` div, which
* is the first child of the *scrolling* list: three hundred rows down, a
* refused rename produced no visible change at all, just a rename box that
* stayed open for no stated reason. The toast host is a persistent `aria-live`
@@ -42,6 +43,28 @@ export function useFileManager(projectId: string) {
* change a sighted user sees in the grid and a screen reader user does not.
*/
const [completed, setCompleted] = useState<string | null>(null);
/**
* Which host transfers are in flight.
*
* Both actions open an OS dialog and can then run for a long time on a large
* file, with nothing on screen to say so. Without this the buttons stay live:
* a second click opens a second dialog and runs a second concurrent exec
* against the same file, and a multi-gigabyte save is indistinguishable from
* a click that did nothing.
*
* `savingPaths` is a **set**, not one path. Keeping only the row being
* disabled is what makes the pane usable during a big transfer — and that is
* precisely what makes a *second* save startable, so the state has to be able
* to hold two. As a scalar it could not: starting a save on `notes.txt` while
* `big.bin` was still streaming overwrote it, so `big.bin`'s button went live
* again mid-transfer; and whichever save finished first cleared the flag for
* both. Dismissing the second dialog was enough to do it.
*
* Paths are unique within a listing, so a path is a usable key — `FilesTab`
* relies on the same fact for its row keys.
*/
const [uploading, setUploading] = useState(false);
const [savingPaths, setSavingPaths] = useState<ReadonlySet<string>>(new Set());
const currentPathRef = useRef(currentPath);
@@ -154,6 +177,86 @@ export function useFileManager(projectId: string) {
[projectId, navigate, report],
);
/**
* Copy host files into the directory on screen.
*
* The picker is opened by **Rust**, not here — `upload_files_to_container`
* shows it, reads what the user chose and never lets a host path near IPC.
* So this passes a directory and gets back an outcome; `null` means the user
* dismissed the dialog, which is not a failure and says nothing.
*
* One dialog can select several files and they need not agree, hence two
* lists. Every failure is reported, because "3 of 5 uploaded" without saying
* which two is not a report. The listing is refreshed once, at the end, and
* only if the user is still looking at the directory that was targeted.
*/
const uploadFiles = useCallback(async () => {
const target = currentPathRef.current;
setUploading(true);
try {
let outcome;
try {
outcome = await commands.uploadFilesToContainer(projectId, target);
} catch (e) {
// A failure *before* the picker: no container, not running, or a
// directory this pane may not write to. One toast, not one per file.
report("Could not upload", e);
return;
}
if (!outcome) return;
for (const failure of outcome.failures) {
useAppState.getState().pushToast({ kind: "error", message: failure });
}
if (outcome.uploaded.length === 0) return;
// The directory is named, not implied. `target` is captured at click time
// and the picker is a modal OS dialog — the user has all the time in the
// world to browse somewhere else while it is open, and the files land
// where they started. "Uploaded 2 files." in front of a grid that does
// not contain them is a worse answer than no message at all.
const count = outcome.uploaded.length;
setCompleted(
`Uploaded ${count === 1 ? "1 file" : `${count} files`} to ${target}.`,
);
if (currentPathRef.current === target) await navigate(target);
} finally {
// Around the *whole* body, refresh included. Clearing it the moment the
// command settled put the button back before the re-listing had run, so
// a second click landed mid-refresh on a grid that was still the old one.
setUploading(false);
}
}, [projectId, navigate, report]);
/**
* Save one file out to the host, with Rust opening the save dialog.
*
* No refresh: nothing in the container changed. The save dialog is also what
* asks about overwriting an existing host file, which is why the backend has
* no collision handling of its own to get wrong. `null` is a dismissal.
*/
const saveToHost = useCallback(
async (entry: FileEntry) => {
setSavingPaths((live) => new Set(live).add(entry.path));
try {
const bytes = await commands.downloadContainerFile(projectId, entry.path);
// `0` is a real answer — an empty file saved is a success — so this
// tests for the dismissal sentinel, not for falsiness.
if (bytes === null) return;
setCompleted(`Saved "${entry.name}" (${formatBytes(bytes)}).`);
} catch (e) {
report(`Could not save "${entry.name}"`, e);
} finally {
// Remove only this one. A save that finishes while another is still
// streaming must not re-enable the other's row.
setSavingPaths((live) => {
const next = new Set(live);
next.delete(entry.path);
return next;
});
}
},
[projectId, report],
);
return {
currentPath,
entries,
@@ -168,5 +271,10 @@ export function useFileManager(projectId: string) {
refresh,
renameEntry,
createFolder,
uploadFiles,
saveToHost,
/** A host transfer is in flight — see the state declarations above. */
uploading,
savingPaths,
};
}
+23 -4
View File
@@ -3,6 +3,7 @@ import { save } from "@tauri-apps/plugin-dialog";
import type { Project } from "../lib/types";
import * as commands from "../lib/tauri-commands";
import { formatBytes } from "../lib/formatBytes";
import { describeResetLeftovers, resetLeftoverPronoun } from "../lib/resetOutcome";
import { useAppState } from "../store/appState";
import { useProjects } from "./useProjects";
import { useTerminal } from "./useTerminal";
@@ -28,13 +29,14 @@ export function useProjectActions(project: Project) {
);
const run = useCallback(
async (label: string, fn: () => Promise<unknown>) => {
async <T,>(label: string, fn: () => Promise<T>): Promise<T | undefined> => {
setBusy(true);
setContainerProgress(project.id, null);
try {
await fn();
return await fn();
} catch (e) {
fail(`${label} failed for “${project.name}”`, e);
return undefined;
} finally {
setContainerProgress(project.id, null);
setBusy(false);
@@ -54,8 +56,25 @@ export function useProjectActions(project: Project) {
);
const handleReset = useCallback(
() => run("Reset", () => rebuild(project.id)),
[run, rebuild, project.id],
() =>
run("Reset", async () => {
const outcome = await rebuild(project.id);
if (outcome.leftover_image || outcome.leftover_volumes.length > 0) {
// Not "run `docker volume rm`" — by the time this renders, the new
// container this same call just started already has the leftover
// volume mounted, so that command would just hit the same 409
// Reset did. Stopping the project first is what actually frees it.
pushToast({
kind: "error",
message: `Reset for “${project.name}” did not fully clean up`,
detail: `Triple-C could not remove ${describeResetLeftovers(outcome)} from before the reset, so \
the new container may still be built from, or contain, old data. Stop the project, then try \
Reset again, or remove ${resetLeftoverPronoun(outcome)} manually once stopped.`,
});
}
return outcome;
}),
[run, rebuild, project.id, project.name, pushToast],
);
const openClaudeTerminal = useCallback(async () => {
+24
View File
@@ -140,3 +140,27 @@ describe("useProjects puts the status back when a refused command never ran", ()
expect(statusOf()).toBe("stopped");
});
});
describe("useProjects.rebuild on success", () => {
it("puts the outcome's project, not the whole outcome, into the list", async () => {
const rebuilt = project("running");
rebuildProjectContainer.mockResolvedValue({
project: rebuilt,
leftover_image: null,
leftover_volumes: [],
});
const { result } = renderHook(() => useProjects());
let outcome!: Awaited<ReturnType<typeof result.current.rebuild>>;
await act(async () => {
outcome = await result.current.rebuild("p1");
});
// A regression here would put the `{ project, leftover_image,
// leftover_volumes }` wrapper into the projects list instead of the
// `Project` it wraps — a shape mismatch `tsc` would not catch inside a
// callback typed to take `unknown` per Tauri's `invoke`.
expect(useAppState.getState().projects.find((p) => p.id === "p1")).toEqual(rebuilt);
expect(outcome.leftover_volumes).toEqual([]);
});
});
+5 -4
View File
@@ -44,8 +44,9 @@ export function useProjects() {
const remove = useCallback(
async (id: string) => {
await commands.removeProject(id);
const report = await commands.removeProject(id);
removeProjectFromList(id);
return report;
},
[removeProjectFromList],
);
@@ -135,9 +136,9 @@ export function useProjects() {
const rebuild = useCallback(
(id: string) =>
withOptimisticStatus(id, "starting", async () => {
const updated = await commands.rebuildProjectContainer(id);
updateProjectInList(updated);
return updated;
const outcome = await commands.rebuildProjectContainer(id);
updateProjectInList(outcome.project);
return outcome;
}),
[updateProjectInList, withOptimisticStatus],
);
+3 -2
View File
@@ -9,8 +9,9 @@
* payload position inside my rect? A hidden pane is `display:none` and so
* has a zero-size rect, which is what stops two panes both claiming the
* same drop. `TerminalView` is the only pane that takes dropped files
* today — the Files pane is container-side only — but the routing is what
* keeps it honest when a second one appears.
* today — the Files pane copies files through buttons and a backend-opened
* dialog, not through a drop — but the routing is what keeps it honest when
* a second one appears.
* 2. **Should the app accept a drop at all right now?** `dropIsBlocked` —
* document-wide, no geometry, no z-order. While a modal or a blocking
* overlay is on screen anywhere, every drop is refused.
+39
View File
@@ -0,0 +1,39 @@
import { describe, it, expect } from "vitest";
import { describeResetLeftovers, resetLeftoverPronoun } from "./resetOutcome";
import type { ProjectResetOutcome } from "./types";
function outcome(overrides: Partial<ProjectResetOutcome> = {}): ProjectResetOutcome {
return {
project: {} as ProjectResetOutcome["project"],
leftover_image: null,
leftover_volumes: [],
...overrides,
};
}
describe("describeResetLeftovers", () => {
it("names the image first, then the volumes", () => {
expect(describeResetLeftovers(outcome({ leftover_image: "x" }))).toBe(
"its previous container image",
);
expect(describeResetLeftovers(outcome({ leftover_volumes: ["v1"] }))).toBe("a volume");
expect(describeResetLeftovers(outcome({ leftover_volumes: ["v1", "v2"] }))).toBe("2 volumes");
expect(
describeResetLeftovers(outcome({ leftover_image: "x", leftover_volumes: ["v1", "v2"] })),
).toBe("its previous container image and 2 volumes");
});
});
describe("resetLeftoverPronoun", () => {
it("is singular for exactly one leftover", () => {
expect(resetLeftoverPronoun(outcome({ leftover_image: "x" }))).toBe("it");
expect(resetLeftoverPronoun(outcome({ leftover_volumes: ["v1"] }))).toBe("it");
});
it("is plural once more than one thing survived", () => {
expect(resetLeftoverPronoun(outcome({ leftover_image: "x", leftover_volumes: ["v1"] }))).toBe(
"them",
);
expect(resetLeftoverPronoun(outcome({ leftover_volumes: ["v1", "v2"] }))).toBe("them");
});
});
+32
View File
@@ -0,0 +1,32 @@
import type { ProjectResetOutcome } from "./types";
/**
* Names what a `ProjectResetOutcome` says Reset could not clear, for
* `useProjectActions`'s Reset toast.
*
* The image is named first and phrased as "its previous container image"
* rather than folded in with the volumes — it is the more serious of the
* two: the new container is built from it whenever it exists, so a
* surviving image means Reset silently rebuilt the exact system layer it
* was asked to discard, while a surviving volume only means old data rides
* along.
*/
export function describeResetLeftovers(outcome: ProjectResetOutcome): string {
const parts: string[] = [];
if (outcome.leftover_image) parts.push("its previous container image");
if (outcome.leftover_volumes.length === 1) parts.push("a volume");
else if (outcome.leftover_volumes.length > 1) parts.push(`${outcome.leftover_volumes.length} volumes`);
return parts.join(" and ");
}
/** How many distinct things `describeResetLeftovers` is describing — the
* image counts as one, however many volumes are named alongside it. */
function resetLeftoverCount(outcome: ProjectResetOutcome): number {
return (outcome.leftover_image ? 1 : 0) + outcome.leftover_volumes.length;
}
/** Pronoun agreement for referring back to `describeResetLeftovers`'s
* output — "remove it manually" for one thing, "remove them" for more. */
export function resetLeftoverPronoun(outcome: ProjectResetOutcome): "it" | "them" {
return resetLeftoverCount(outcome) === 1 ? "it" : "them";
}
+22 -3
View File
@@ -1,5 +1,5 @@
import { invoke } from "@tauri-apps/api/core";
import type { Project, ProjectPath, ContainerInfo, AppSettings, UpdateInfo, ImageUpdateInfo, FileEntry, FileContents, WebTerminalInfo, SttStatus, GatewayStatus, InstallOptions, ClaudeSession, ContainerCapabilities, ScheduledTask, ScheduledTaskInput, SchedulerNotification, AuthBridgeStatus, BrowserViewStatus, BrowserViewPopoutState, BrowserPageState, PlaywrightDetection, BrowserSetupOutcome, BrowserInstallTarget, ContainerStaleness, MigrationOptions, MigrationReport, MigrationState, ClearTokenOutcome, CaCertInfo } from "./types";
import type { Project, ProjectPath, ProjectRemovalReport, ProjectResetOutcome, ContainerInfo, AppSettings, UpdateInfo, ImageUpdateInfo, FileEntry, FileContents, WebTerminalInfo, SttStatus, GatewayStatus, InstallOptions, ClaudeSession, ContainerCapabilities, ScheduledTask, ScheduledTaskInput, SchedulerNotification, AuthBridgeStatus, BrowserViewStatus, BrowserViewPopoutState, BrowserPageState, PlaywrightDetection, BrowserSetupOutcome, BrowserInstallTarget, ContainerStaleness, MigrationOptions, MigrationReport, MigrationState, ClearTokenOutcome, CaCertInfo, UploadOutcome } from "./types";
// Docker
export const checkDocker = () => invoke<boolean>("check_docker");
@@ -13,7 +13,7 @@ export const listProjects = () => invoke<Project[]>("list_projects");
export const addProject = (name: string, paths: ProjectPath[]) =>
invoke<Project>("add_project", { name, paths });
export const removeProject = (projectId: string) =>
invoke<void>("remove_project", { projectId });
invoke<ProjectRemovalReport>("remove_project", { projectId });
export const updateProject = (project: Project) =>
invoke<Project>("update_project", { project });
export const startProjectContainer = (projectId: string) =>
@@ -21,7 +21,7 @@ export const startProjectContainer = (projectId: string) =>
export const stopProjectContainer = (projectId: string) =>
invoke<void>("stop_project_container", { projectId });
export const rebuildProjectContainer = (projectId: string) =>
invoke<Project>("rebuild_project_container", { projectId });
invoke<ProjectResetOutcome>("rebuild_project_container", { projectId });
export const reconcileProjectStatuses = () =>
invoke<Project[]>("reconcile_project_statuses");
@@ -69,6 +69,25 @@ export const stopAudioBridge = (sessionId: string) =>
// Files
export const listContainerFiles = (projectId: string, path: string) =>
invoke<FileEntry[]>("list_container_files", { projectId, path });
/**
* Save one container file to the host.
*
* The **backend** opens the save dialog, so this call cannot name a place on
* the host — that is the point (see `pick_save_path` in `file_commands.rs`).
* Paths do come *back* inside error text; what is closed is the inbound
* direction.
* Resolves to the number of bytes written, or `null` if the user dismissed the
* dialog. Zero bytes is a success: an empty file is a file.
*/
export const downloadContainerFile = (projectId: string, containerPath: string) =>
invoke<number | null>("download_container_file", { projectId, containerPath });
/**
* Upload host files into `containerDir`, with the backend opening the file
* picker. Resolves to `null` if the user dismissed it, otherwise to what
* happened — one dialog can select several files and they need not all succeed.
*/
export const uploadFilesToContainer = (projectId: string, containerDir: string) =>
invoke<UploadOutcome | null>("upload_files_to_container", { projectId, containerDir });
export const downloadContainerBackup = (projectId: string, hostPath: string, containerPath?: string) =>
invoke<number>("download_container_backup", { projectId, hostPath, containerPath });
export const readContainerFile = (projectId: string, path: string, maxBytes?: number) =>
+47
View File
@@ -77,6 +77,37 @@ export type ProjectStatus =
| "stopping"
| "error";
/** What `removeProject` could not delete. The project is removed from the
* sidebar either way. When `retry_scheduled` is true, anything named here
* was recorded on the host and will be retried automatically the next time
* the app starts; when false, the record itself could not be saved and
* nothing will retry it. `retry_scheduled` is meaningless when nothing was
* left behind. */
export interface ProjectRemovalReport {
container: string | null;
image: string | null;
volumes: string[];
retry_scheduled: boolean;
}
/** True when a `ProjectRemovalReport` left nothing behind. Mirrors the
* Rust-side `ProjectRemovalReport::is_clean`. */
export function projectRemovalIsClean(report: ProjectRemovalReport): boolean {
return !report.container && !report.image && report.volumes.length === 0;
}
/** What Reset (`rebuildProjectContainer`) produced: the project as it stands
* after restarting, and any volume Reset could not clear — which is reused
* as-is by the new container instead of starting clean. */
export interface ProjectResetOutcome {
project: Project;
/** The saved container image, if Reset could not remove it — the new
* container is built from it whenever it exists, so this means Reset
* silently rebuilt the system layer it was asked to discard. */
leftover_image: string | null;
leftover_volumes: string[];
}
export type Backend =
| "anthropic"
| "bedrock"
@@ -365,6 +396,22 @@ export interface FileEntry {
permissions: string;
}
/**
* What one upload dialog's worth of files did — mirrors `UploadOutcome` in
* `commands/file_commands.rs`.
*
* Two lists rather than a count and a flag, because one dialog can select
* several files and they do not have to agree: a folder among the selection, or
* a file over the size ceiling, must not cost the user the ones either side of
* it. Each `failures` entry is already a finished sentence naming its file.
*/
export interface UploadOutcome {
/** In-container paths, in the order they landed. */
uploaded: string[];
/** One sentence per file that did not. */
failures: string[];
}
/** A file read out of the container for the in-app viewer. */
export interface FileContents {
/** Base64 — a byte array would cross IPC as JSON numbers. */
+86
View File
@@ -0,0 +1,86 @@
# Maintainer: Triple-C Contributors
#
# This file is regenerated by .gitea/workflows/publish-aur-package.yml on every
# publish — pkgver, the source URL and sha256sums are rewritten from the real,
# already-uploaded release asset, never guessed. Editing pkgver/source/
# sha256sums by hand here only matters until the next automated run overwrites
# them; everything else (depends, pkgdesc, package()) is meant to be hand-
# maintained normally.
#
# "-bin" rather than building from source: this repackages the same .deb
# build-app.yml already produces and publishes, so a user gets exactly the
# binary the project ships and tests, and `makepkg` never needs a Rust
# toolchain, Node, or the dozen -dev packages CLAUDE.md lists for building
# Triple-C itself. The trade-off is the one every "-bin" package makes: it
# assumes the glibc the CI runner (Ubuntu 24.04) linked against is compatible
# with the installing system's — true for essentially every currently
# supported Arch install, since Arch tracks glibc newer than Ubuntu 24.04
# ships, and forward compatibility is the direction that holds.
pkgname=triple-c-bin
pkgver=0.4.0
pkgrel=1
pkgdesc="Sandbox Claude Code inside Docker containers"
arch=('x86_64')
url="https://github.com/shadowdao/triple-c"
license=('MIT')
# Verified against a real release asset (v0.4.14), not Tauri's generic docs:
# downloaded Triple-C_0.4.14_amd64.deb, installed each of these into a real
# Arch container, and re-ran `ldd` on the actual binary until nothing came
# back "not found". `pango` and `libayatana-appindicator` were both in an
# earlier draft — pango isn't directly linked (gtk3 already pulls it in
# transitively, and namcap correctly flags declaring it as redundant), and
# libayatana-appindicator is in Tauri's own linux dependency list but this
# binary never links it at all: there is no tray icon or menu in this app
# (see CLAUDE.md's note that `core:menu`/`core:tray` are dropped for the
# same reason), so it was never a real dependency to begin with.
depends=('cairo' 'desktop-file-utils' 'gdk-pixbuf2' 'glib2' 'gtk3'
'hicolor-icon-theme' 'libsoup3' 'webkit2gtk-4.1')
optdepends=('docker: to actually run the sandboxed containers'
'xdg-utils: opening links from the app in your default browser')
provides=('triple-c')
conflicts=('triple-c')
# !strip: the upstream .deb's binary is already the release build Tauri
# produced and tested; re-stripping a prebuilt binary is unnecessary risk for
# no benefit. It's also what actually suppresses makepkg's debug-package
# machinery here (debug-package extraction requires strip; verified in a
# real build — with !strip alone, no debug package is produced at all).
# !debug is kept anyway, explicit about intent rather than relying on that
# side effect. Without either, makepkg built a usr/src/debug/triple-c-bin
# tree containing a dangling .build-id symlink, which is a real namcap
# error (not just the empty-directory warning it looks like) — there is no
# debug info in this release binary for the machinery to have extracted in
# the first place.
options=('!strip' '!debug')
# Tauri names the asset after `productName` verbatim ("Triple-C"), not the
# lowercase Cargo binary name — verified against the real release, not
# assumed; a lowercase guess here would 404. The LICENSE fetch is separate
# because the .deb itself carries no license file — namcap flags an MIT
# package with nothing under /usr/share/licenses/ as an error, correctly.
source=("Triple-C_${pkgver}_amd64.deb::https://github.com/shadowdao/triple-c/releases/download/v${pkgver}/Triple-C_${pkgver}_amd64.deb"
"LICENSE::https://raw.githubusercontent.com/shadowdao/triple-c/v${pkgver}/LICENSE")
sha256sums=('SKIP'
'SKIP')
package() {
cd "$srcdir"
# A .deb is an ar archive of debian-binary, control.tar.*, data.tar.* — `ar`
# (part of base-devel's binutils) pulls just the payload out. Extracting
# that tar directly into $pkgdir works here with no path rewriting at all:
# verified against the real archive, whose entire payload is
# usr/bin/triple-c, usr/share/applications/Triple-C.desktop and
# usr/share/icons/hicolor/*/apps/triple-c.png — Tauri's Linux bundle for
# this app carries no separate resource directory under usr/lib/, so there
# is nothing that could disagree between Debian's and Arch's package trees
# for it to land in the wrong place.
#
# Globbed rather than named literally: the publish workflow discovers the
# real asset name from the release itself specifically so a Tauri bundler
# naming change can't silently break this — naming the file again here
# would throw that away and fail this one line with an opaque "No such
# file or directory" instead. `source=()` above guarantees exactly one
# `*_amd64.deb` entry, so the glob can only ever match that one file.
ar x ./*_amd64.deb
tar xf data.tar.* -C "$pkgdir"
install -Dm644 "$srcdir/LICENSE" "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}
+53
View File
@@ -0,0 +1,53 @@
# Arch / CachyOS package
`PKGBUILD` here is the AUR `triple-c-bin` package's template — see triple-c#34
(the "I would like to also have an Arch/CachyOS native version" part of it).
## Why "-bin"
It repackages the same `.deb` `build-app.yml` already produces, rather than
building from source. That means `makepkg` never needs a Rust toolchain,
Node, or the dozen `-dev` packages CLAUDE.md lists for building Triple-C
itself — and a user gets exactly the binary the project ships and tests,
built on Ubuntu 24.04 in CI. Verified end to end against a real release
(v0.4.14): downloaded the actual `.deb`, confirmed every `depends` entry
against a real `ldd` of the actual binary (two packages that looked right
from Tauri's own docs — `pango`, `libayatana-appindicator` — turned out not
to be real dependencies of *this* binary and were dropped), and ran a real
`makepkg`/`namcap`/`pacman -U` cycle rather than guessing at the shape.
## Publishing
`.gitea/workflows/publish-aur-package.yml` does the actual work: given a
version (or "latest" if none is given), it finds that release's real Linux
asset on GitHub, downloads it, computes real checksums, renders this
template into a version-specific PKGBUILD, validates it with `makepkg` and
`namcap` inside a real Arch container, and pushes the result to AUR.
It is `workflow_dispatch`-only, deliberately — see the workflow file's own
header comment for why an automatic trigger isn't safe here (the same reason
`sync-release.yml` didn't work and was removed in triple-c#32).
**Before it can push anything**, an AUR account has to exist and the
`triple-c-bin` package has to have been created (or you added as a
co-maintainer) under it — both are one-time, manual steps on
https://aur.archlinux.org, since there's no API to automate creating an
account or a new package. Once that's done, add the account's SSH private
key as the `AUR_SSH_PRIVATE_KEY` secret on this repo. Until that secret
exists, the workflow fails at the "Push to AUR" step with a message saying
so, rather than silently doing nothing.
## What's hand-maintained vs. generated
`pkgver`/`pkgrel`/`source`/`sha256sums` in this file are placeholders —
the workflow rewrites them for every real publish and never commits the
result back here, so don't read this file's `pkgver` as "the last published
version." Everything else (`depends`, `pkgdesc`, `package()`) is meant to be
edited by hand normally, the same as any other PKGBUILD.
**A hand-edit made directly in the AUR repo is silently overwritten the
next time this workflow runs.** Every run renders fresh from *this*
repo's template rather than starting from whatever AUR's copy currently
looks like, so a quick fix pushed straight to AUR (bumping `pkgrel` for a
packaging-only issue, say) survives only until the next dispatch. Make
the fix here instead.
+111
View File
@@ -0,0 +1,111 @@
#!/bin/sh
# Refuse to let a live credential into the repository.
#
# Written after one got in: `the_custom_env_fingerprint_never_carries_the_value`
# used the maintainer's real Gitea site-admin token as its fixture. It survived
# 92 commits and fourteen days in a public mirror, past five audit rounds and two
# independent reviews — because every one of those looked at the code under
# change, and this sat in a test nobody had reason to open. A grep would have
# caught it on the first day. This is that grep.
#
# Usage:
# scan-secrets.sh --staged what `git commit` is about to record (the hook)
# scan-secrets.sh --range A..B every line added between two commits (CI)
# scan-secrets.sh --tracked every tracked file, as it stands now
#
# Exit 0 clean, 1 on a finding, 2 on misuse.
#
# ## Why it scans *added lines* and not the whole file
#
# The repository already contains long opaque strings — 317 literals of 32+
# characters, almost all of them legitimate. A scanner that failed on those would
# be turned off within a day, which is the normal way this kind of check dies.
# Judging only what a commit *adds* keeps the signal where a person can act on it.
#
# ## Escape hatch
#
# A line carrying `pragma: allowlist secret` is skipped. Deliberately wordy: it
# should be uncomfortable enough to type that it is read as a claim, and it
# leaves something greppable behind.
set -eu
MODE="${1:---staged}"
RANGE="${2:-}"
case "$MODE" in
--staged) ADDED=$(git diff --cached --unified=0 --no-color -- . 2>/dev/null || true) ;;
--range) [ -n "$RANGE" ] || { echo "scan-secrets: --range needs A..B" >&2; exit 2; }
ADDED=$(git diff --unified=0 --no-color "$RANGE" -- . 2>/dev/null || true) ;;
--tracked)
# `grep -Iq .` first: without it a binary blob's bytes reach the
# rules below, and GNU grep answers "binary file matches" instead
# of the line — so a real finding inside one would be reported as
# a sentence nobody can act on, and a stray NUL can end the scan
# early. Text files only; binaries are not where source secrets
# live, and `--staged` never sees them either (git emits
# "Binary files differ", not content).
ADDED=$(git ls-files -z \
| xargs -0 -I{} sh -c 'grep -Iq . "{}" 2>/dev/null && sed "s/^/+/" "{}" 2>/dev/null' \
|| true) ;;
*) echo "scan-secrets: unknown mode $MODE" >&2; exit 2 ;;
esac
# Only added lines; drop diff headers (+++ b/path) so a filename never matches.
CANDIDATES=$(printf '%s\n' "$ADDED" \
| grep '^+' \
| grep -v '^+++' \
| grep -v 'pragma: allowlist secret' \
|| true)
[ -n "$CANDIDATES" ] || exit 0
FOUND=0
report() {
FOUND=1
printf '\n %s\n' "$1"
printf '%s\n' "$2" | sed 's/^/ /' | cut -c1-160
}
# --- Rule 1: vendor-issued credentials. Shape alone identifies these, so there
# --- is no false-positive story to tell and no identifier context needed.
VENDOR=$(printf '%s\n' "$CANDIDATES" | grep -nE \
'gh[pousr]_[A-Za-z0-9]{20,}|github_pat_[A-Za-z0-9_]{20,}|glpat-[A-Za-z0-9_-]{20,}|xox[baprs]-[A-Za-z0-9-]{10,}|sk-[A-Za-z0-9]{32,}|AKIA[0-9A-Z]{16}|ASIA[0-9A-Z]{16}|ya29\.[A-Za-z0-9_-]{20,}|AIza[0-9A-Za-z_-]{35}|npm_[A-Za-z0-9]{36}|dckr_pat_[A-Za-z0-9_-]{20,}' \
|| true)
[ -n "$VENDOR" ] && report "A vendor-issued credential (its prefix identifies the provider):" "$VENDOR"
# --- Rule 2: private key material.
KEYS=$(printf '%s\n' "$CANDIDATES" | grep -nE -- '-----BEGIN [A-Z ]*PRIVATE KEY-----' || true)
[ -n "$KEYS" ] && report "Private key material:" "$KEYS"
# --- Rule 3: an opaque literal assigned to a secret-shaped name.
#
# This is the rule that would have caught the Gitea token — `let secret =
# "<40 hex>"`. Both halves are required, and that is what keeps it usable:
# the *name* must read as a credential, and the *whole literal* must be hex or
# base64 with no word structure. `"aws-secret-access-key"` is a keychain key
# name sitting right next to the word `secret`, and its hyphens are what keep it
# out; measured against the tree, name-proximity alone flagged four lines of
# which three were that shape.
OPAQUE=$(printf '%s\n' "$CANDIDATES" | grep -niE \
'(secret|token|api[_-]?key|apikey|passwo?rd|passwd|credential|auth[_-]?(key|token))[^A-Za-z0-9]{0,12}[:=][^"'"'"']{0,12}["'"'"']([0-9a-fA-F]{32,}|[A-Za-z0-9+/]{40,}={0,2})["'"'"']' \
|| true)
[ -n "$OPAQUE" ] && report "An opaque literal assigned to a secret-shaped name:" "$OPAQUE"
if [ "$FOUND" -eq 1 ]; then
cat >&2 <<'MSG'
────────────────────────────────────────────────────────────────────────
Refusing the commit: it adds something shaped like a live credential.
If it IS live: do not amend and move on. Rotate it first — anything that
reaches a branch is on the mirror, and the mirror is public.
If it is genuinely not a secret — a fixture, a public key id, test data —
make the literal obviously fake ("not-a-real-token-0000…"), or append
`pragma: allowlist secret` to the line to say so on the record.
────────────────────────────────────────────────────────────────────────
MSG
exit 1
fi
exit 0