Changelog

All notable user-facing changes to TumbleTrove Desktop are tracked here. The format follows Keep a Changelog, and the project adheres to Semantic Versioning.

This file is mirrored at docs.tumbletrove.com/changelog.

Internal-only changes (CI plumbing, lint fixes, refactors, dependency bumps that don't affect behaviour) are intentionally omitted — see the git history for the full record.

[0.49.3] – 2026-08-05

Fixed

• The Packages tab now tells you which version of a package you actually have. A package's page listed the projects using it and, beside each one, the word "unpinned" — and almost nothing else. That word is the normal state rather than an unusual one: adding a package to a project tracks its latest version instead of fixing it to a particular one, so unless you had deliberately chosen a version, the page named no version at all, for that package or any other. Each project now shows the version on your machine that it uses, and a new Installed section lists every copy of the package you have, each with a button to open its folder — so a package you own but haven't added to a project yet also has something to show. One related fault is fixed with it: a package you had pinned to a specific version could still be described as unpinned, because the page checked the project against the package one way when deciding it was in use and a stricter way when looking up the version. Note what is shown is what is on this machine now, not necessarily what you will get next: a package tracking the latest version is re-checked against the registry each time the project launches, so a release published since your last launch appears after the next one. Reported by Roy.
• An account whose username contains an underscore can create projects again. Creating a project failed outright, with an error about ASCII that pointed at nothing you could act on. Preparing a project writes a small manifest naming you as its owner, and the package manager reading that file accepts only lowercase letters, digits and hyphens in a name — so an underscore made the whole file unreadable and stopped the project being created at all. There was no way around it from inside the app; the one person who reported it recovered by abandoning the account and making another. Your name is now converted to a form the package manager accepts, so the account you already have keeps working and nothing about it needs changing. The same fault affected any project whose name was written in a script other than the Latin alphabet, which failed the same way and for the same reason; those now work too. Reported by Noah.

[0.49.2] – 2026-08-05

Fixed

• A package that was already installed when its tools stopped working on macOS and Linux now repairs itself, as part of updating. 0.48.1 fixed the mark that tells the system a package's tool is a program it may launch, but only for packages built or unpacked from that point on — a package already on your machine was never unpacked again, so its Configure… button went on failing with a permissions error no matter how many times you updated TumbleTrove. That was the situation for anyone who had installed such a package before the fix, and there was no way out of it from inside the app: the wizard that fills in a package's required values wouldn't start, and launching the project — the one action that would have refreshed the package — refuses to run while those values are empty. Updating TumbleTrove is now all that is needed: every installed package is checked and repaired as the app starts, before you go looking for the problem. Anything that slips through that check is repaired at the moment it is run instead, so no tool a package ships should ever need marking by hand. The repair only ever marks files that genuinely are programs, it leaves everything else exactly as it is, and it costs nothing once a package has been checked. A package you have linked as a development copy is left out of the start-up check on purpose — that is your own working copy, and its files stay as your build made them until you actually try to run one that can't start. Reported by Martin.

[0.49.1] – 2026-08-04

Fixed

• A package's setup wizard now actually applies the values it produces. Running a package's Configure… wizard — by hand, or automatically for a variable a package marks as required — appeared to do nothing: the wizard opened, you filled it in, it closed reporting success, and the variable it set was still empty. The wizard was never at fault. The app read its answer using the wrong name for one field and, finding nothing under the name it looked for, quietly treated the reply as "no changes" instead of reporting that it hadn't understood. Nothing surfaced the discrepancy, because an empty answer is a legitimate one. This affected every package setup wizard since the feature was introduced in April, and equally the variables a package supplies at launch time, which were being discarded the same way. Both now work. If a hook's reply can't be understood in future, the log says so instead of passing over it.

[0.49.0] – 2026-08-03

Added

• A package that needs a value from you now opens its own setup wizard. A package can declare a variable it cannot fill in itself and leave the value to the project; until one is supplied, installing the project fails. Where the package ships a Configure… wizard that produces exactly that value, the project editor now runs it for you as soon as it sees the gap, instead of waiting for you to notice the button. It runs only for the package's own unfilled variables, never for a package you have switched off, and at most once per package each time you open the editor — so a wizard you close stays closed, and the Configure… button is still there to run it again whenever you want.

Fixed

• The browser developer tools are no longer bundled into the released app. Right-clicking inside any TumbleTrove window offered an Inspect Element entry that opened a web inspector over the app — a development aid that was never meant to reach released builds, and which exposed the app's internals to anyone who happened to right-click. It is now built only into development builds, where it belongs. Nothing about how the app works changes. Reported by Storm against the Logs window; it was in fact present in every window.
• Your packages no longer look deleted because of a stray setting. TumbleTrove supplied its own package registry only when you had none of your own configured, so adding a single registry — or leaving behind an old one that no longer answers — quietly took TumbleTrove's out of the picture on that machine. Every package then looked missing: the project editor announced that packages were "no longer available" and offered to remove them from your projects, when nothing was wrong with the packages at all. Because the setting is per-machine, the same project could be fine on one computer and broken on another, which reads as a fault with that operating system rather than a setting. TumbleTrove's registry is now always present, added alongside anything you have configured rather than instead of it — yours is still consulted first — and it is restored automatically if it ever goes missing again.
• The log now records how a package's hook finished. A setup or launch hook that a package provides wrote a line to tumbletrove.log when it started and nothing at all when it ended, so a wizard you closed without completing looked identical to one still waiting for you — in both cases the log simply stopped. Each hook now also records the code it exited with and how much it sent back, and, separately, the names of any variables it set. Values are never written down, only names and sizes, so the log stays safe to attach to a bug report.

[0.48.1] – 2026-08-02

Fixed

• A package's Configure button — and any tool a package ships — now runs on macOS and Linux. Clicking Configure… on a package that provides its own setup program failed immediately with a permissions error, while the very same package worked normally on Windows, so it looked like a Mac and Linux fault rather than what it actually was. A package arrives as an archive, and that archive records, per file, whether the file is a program the system is allowed to launch. The mark was being dropped when the package was built, so the setup program was installed as an ordinary data file and the system refused to start it; Windows was unaffected only because it decides what counts as runnable a different way. Packages are now built with the mark intact, and it is also restored as a package is unpacked — so this is fixed regardless of who built the package or what they built it with. Two things worth knowing: a package already on your machine keeps the files it was installed with until a new version of it comes out, and if a tool still refuses to start, the error now names the exact file and what is wrong with it instead of reporting a bare permissions code.

• The app no longer resets your projects when the real problem is the folder they live in. If the database couldn't be opened, the app assumed the file was damaged, moved it into a recovery-… folder and built a fresh one. That's the right response to a damaged file and the wrong one to a home directory the app can't write to, is out of space, or lives on a network share — none of which are fixed by starting over, so the app failed anyway and moved another copy aside the next time you opened it. It now tells these apart: a damaged database still repairs itself as before, while a folder-level problem is reported with what to check and your database is left exactly where it is. Relatedly, on a network-mounted home directory the app previously refused to start at all, because it insisted on a faster database mode that network shares don't support; it now falls back to the ordinary mode and starts.

[0.48.0] – 2026-07-31

Added

• The project editor now asks for the values a package needs from you. A package can declare a variable it cannot fill in itself — a licence server address, a studio share path — and leave the value to the project. Until now the editor showed no field for those at all: the first sign that something was missing came when installing the project failed part-way through, naming one variable at a time and telling you to hand-edit a file the app maintains. The editor now lists each one as an empty field marked required, and warns above the package list while any are unfilled, so they can be dealt with before installing. A package offering a Configure… wizard can still fill in its own. If you had worked around the missing field by adding the variable by hand, your value moves onto that package's card and keeps working — nothing to redo. This only covers variables a package explicitly declares as required — one it needs but never declares stays invisible, so package authors: see the docs on marking a variable required.

Fixed

• Installing or launching a project now tells you up front which values it still needs. When a package requires a value the project hasn't supplied, it used to fail part-way through — after downloading Houdini, and naming only the first missing variable, so a project short of three revealed them one attempt at a time. The check now runs first and lists all of them at once, naming the package each belongs to and pointing at the field that fills it, so nothing is downloaded before you can act on it. A value of only spaces no longer counts as filled in: it used to pass unnoticed and hand Houdini a blank setting, which failed later in ways that didn't mention the variable at all.
• A package's Configure button now appears as soon as you add the package. Adding a package that offers a Configure… wizard showed no button for it — the card looked like any other package, and the only way to get the button was to close the project editor and open it again. The editor asked two separate questions about each package: what environment variables it declares, and whether it offers a wizard. Only the first could fetch a package this machine didn't have yet, and the second was asked first, so for a package you'd just added the answer was always "no wizard" and nothing asked again. Both questions are now answered together, from one look at the package.
• Configure wizards can no longer lose values that the package doesn't declare itself. A wizard sets environment variables for your project; some of them are values the package declares a slot for, others are project-level settings the wizard produces on its own — a license server address, say. The second kind was filed against the package that produced it, so it was invisible in the editor and was discarded the next time the editor re-checked what the project's packages declare, saving the loss. Those values now become ordinary project environment variables, visible and editable in the Environment Variables section straight after the wizard runs.
• A package you have linked to a local working copy is now read from that copy everywhere. With a development override linked for a project, the editor still showed the published version's environment variables and wizard, while running a script or wizard used your working copy. The two now agree on your working copy.

[0.47.1] – 2026-07-29

Fixed

• Deleting a project's environment variables now sticks. Removing every environment variable from a project appeared to work, but restarting the app brought them all back. Your projects are synced to your TumbleTrove account, and the app had no way to tell the account "this project now has none" — an empty list was sent as no instruction at all, so the account kept the old values and handed them back on the next start. The same applied to the combine method (set / prepend / append) on each variable. Emptying the list is now sent as a real change. One caveat while this settles: if you use TumbleTrove on more than one machine, clearing a project's variables on a machine that hasn't synced recently can now clear them for that project everywhere, so let a machine finish syncing before emptying a list on it.
• A package's Configure step no longer loses the values it set. Running a package's Configure… wizard writes environment variables into the project — the project path a pipeline package needs, for instance. Those values could disappear again later, leaving the variable blank as though the wizard had never run, and re-running it only bought time. Two separate faults erased them. The app syncs your projects to your TumbleTrove account, and it pulls that copy on every start; if the matching upload hadn't gone through yet — you were offline, or the app was closed too soon after the edit — the pull replaced your project with the account's older copy and discarded the pending upload, so the value was lost on this machine and never reached your account. Separately, if the app couldn't read the packages' declared variables at the moment you had the project open (a brief connection problem, or packages not yet installed on a new machine), the editor concluded that no package claimed those variables and cleared every one of them, then saved and uploaded that as an intentional change. Edits waiting to upload are now kept instead of being overwritten, and the editor no longer treats "couldn't check" as "nothing declares these". Values already lost need setting again.
• Renaming a project no longer makes a duplicate of it reappear. Renaming a project and restarting the app brought the old name back as a second project alongside the renamed one, with the original's settings. Renaming created a fresh entry in your TumbleTrove account rather than updating the existing one, and the leftover was handed back on the next start. The leftover is now cleaned up, including when the rename was made offline — it is finished the next time the app syncs.
• Projects still sync for people with more than 100 of them. Uploading sent every changed project in a single request, which is over the limit the account API accepts. The whole upload was rejected rather than partially applied, so nothing reached your account and nothing said so. Uploads are now sent in batches.

[0.47.0] – 2026-07-29

Added

• The project editor now tells you when a package in a project is no longer available, and offers to fix it. Packages can disappear underneath a project you already set up — the creator archives or unpublishes one, or the exact version you pinned gets yanked or withdrawn. Until now nothing said so: the package quietly went missing at launch, and on a team project the whole project refused to save — even a rename — until you worked out which entry was dead and deleted it by hand. Opening a project now checks its package list and, if anything has rotted, shows a warning with a Review and fix button. The dialog names each package, explains what happened, and lets you either update it to the newest available version or remove it from the project, in one pass. The same dialog now appears when publishing a team project is rejected for that reason, so you can prune the offending packages and publish straight from it. Packages you have linked to a local folder are left alone, and if the check can't reach the registry (offline, for instance), nothing is reported — it will never suggest removing a package it couldn't actually verify.

Fixed

• Deleting a project now sticks. A project you deleted came back the next time you started TumbleTrove Desktop. Deleting removed it from this machine, but not from your TumbleTrove account — and since the app pulls your projects from your account on every start, the project you had just deleted was handed straight back. Deleting a project now removes it from your account too, so it stays gone here and on your other machines. If the app can't reach TumbleTrove at the moment you delete (offline, for instance), the project still disappears immediately and the deletion is finished the next time the app syncs — it will not reappear in the meantime.
• Projects pinned to a Houdini 22 release-candidate build no longer claim the build is missing. Houdini 22 sometimes carries a fourth version number (22.0.637.6 on disk, listed as build 637), and while such a project launched perfectly well, the project list offered "Install" instead of "Launch" and the project editor warned that the build "isn't installed on this machine". Both now recognise the installed build, matching it exactly the way launching does.
• A Houdini version you install while TumbleTrove is running now shows up in the project's version picker, without restarting the app. Installing a build in the SideFX Launcher (or anywhere outside TumbleTrove) left the Houdini Version and Build dropdowns showing whatever was on disk when the app started — the new build only appeared after a full restart. The app now re-checks for installed Houdini versions whenever you switch back to its window, every time you open a project, and every time you open either version dropdown, so a build installed a moment ago is there when you go looking for it. A newly found install also shows up when the SideFX build list can't be reached at all (offline, or no linked SideFX account), which previously hid it as well.

[0.46.1] – 2026-07-27

Fixed

• Package hooks and scripts that point at a bundled tool now run on Windows. A package declaring its command as a path inside its own folder — for example bin/windows-x86_64/tt_setup.exe, the usual way to ship one tool per platform — failed on Windows with "The system cannot find the path specified", while the identical package worked on macOS and Linux. Windows looked the tool up relative to wherever TumbleTrove Desktop itself was started from instead of the package folder. This affected the Configure button, project and package scripts, and dev-package builds; all of them now find the tool.
• Publishing to SideFX now works for packages with a bounded Houdini range. A package whose [compat].houdini used a caret, tilde, or upper-bounded range (^21, ~21.5, >=21, <22.5) was rejected before upload with a complaint that it declared no minimum Houdini version — even though it clearly did. The check was tripping over the range's upper bound and discarding the valid minimum sitting right next to it. Caret and tilde ranges now publish; a comma-separated range with an explicit upper bound is still affected and is being addressed separately.
• Packages packed through TumbleTrove Desktop can now be installed into Houdini by hand, without hpm. A packed archive is meant to be extractable straight into a Houdini packages directory, but two problems made that fail: the content was packed flat rather than in the folder layout Houdini's package file points at, and a package that listed any dependency was emitted with a hard requires that Houdini could not satisfy on a manual install, disabling the whole package. Both are fixed (via hpm 0.30.1), so a hand-extracted package — including one with dependencies — now loads. Verified against Houdini 21.0.729 and 22.0.368. Packages installed through TumbleTrove or hpm were never affected.

[0.46.0] – 2026-07-23

Changed

• Turning a custom variable or a package off on a team project is now shared with your team. These toggles used to be local to your own machine (as the 0.45.0 notes described) — they are now part of the project's shared configuration. When someone who can edit the team project switches a variable or package off and clicks Publish, everyone on the team picks up the change on their next sync. The disabled item stays defined on the project, so its value and settings survive, but it is skipped when Houdini launches — letting a team retire a variable or package together without deleting it. As with any other team-project edit, a toggle stays a local pending change until you Publish it, so you can still test the effect before sharing it.

Fixed

• When saving a team project is blocked by a package that can't be published, the app now tells you which package and why. If a project's package list includes something that can no longer be published — for example a package that has since been archived — the save is rejected. That rejection used to surface as a raw, unreadable error; it now names each offending package, explains why it is blocked, and points to the fix. This also covers creating a project and the build-recovery prompt, which previously showed only a generic failure.

[0.45.1] – 2026-07-21

Fixed

• On Linux .deb/.rpm installs, the updater no longer fails when you try to install an update. In-place self-update only works for the AppImage build, so clicking "Download & Install" on a packaged install used to end in an "only an AppImage can be updated" error. Those installs now recognise that an update exists but point you to the TumbleTrove website to get the latest version (and update through your package manager), instead of attempting — and failing — an in-app install. The AppImage build is unaffected.
• Launch-at-login keeps working after you replace the Linux AppImage with a newer download. The autostart entry stored the exact path of the AppImage it was set up with, so downloading a new versioned .AppImage (and removing the old one) left login-time startup pointing at a file that no longer existed. The entry's path is now refreshed on every launch — only while you have launch-at-login switched on, so turning it off still sticks.
• The Linux .deb no longer shows a blank window on NVIDIA GPUs. WebKitGTK's default DMA-BUF renderer draws nothing on the NVIDIA proprietary driver, so the app window came up empty. The workaround that already covered the AppImage now also applies to .deb installs when the NVIDIA driver is detected; AMD and Intel machines keep the faster default. You can still override it by setting WEBKIT_DISABLE_DMABUF_RENDERER=0.
• The Linux AppImage no longer crashes when you open a folder or image picker. On desktops using an SVG-based icon theme (such as Papirus), pressing "Add Directory" in Settings → Houdini — or any other file/folder picker — aborted the whole app with a gdk-pixbuf/libpixbufloader-svg.so error. The AppImage advertised an SVG icon loader it did not actually ship; the app now detects that and falls back to your system's icon loaders, so the native pickers open normally. This only affected the AppImage build.

[0.45.0] – 2026-07-21

Added

• You can now switch a custom project variable off without deleting it. Each row in a project's Custom Variables section has an enable/disable toggle. A disabled variable keeps its name, value, and combine method but is not applied when you launch Houdini (or run a project script), so you can park a variable you're not using — or temporarily take one out of the mix while debugging — and switch it back on later without retyping it. For team projects the toggle is local to your machine, exactly like the per-package disable, and is not published to teammates.

Security

• Logs no longer contain your credentials, your identity, or your projects' secrets, so they're safe to attach to a bug report. Previously a Houdini launch wrote every environment variable it passed to Houdini — including your own project env vars and anything a tt_prepare hook exported, which are commonly render-farm tokens and studio credentials — into both the launch log and the main app log. Values are now shown only for variables TumbleTrove sets itself; everything else is recorded as <redacted> with its name kept, so you can still see which variables were set. That includes your own identity (TT_USER_EMAIL, TT_USER_NAME) and your project's name (TT_PROJECT_NAME, HOUDINI_USER, HOUDINI_SPLASH_MESSAGE) — all still passed to Houdini, scripts, and hooks exactly as before, simply no longer written down. Logs now identify a project by its id, which they already did in the filename, so an unannounced production title never lands in a file you might send us. The same masking covers the generated hpm.toml, script and hook command lines (which previously had $VAR references expanded to their values), and API responses.
• The log file is now scrubbed as it is written, not just when you export it. Home directory paths, usernames, email addresses, tokens, and OAuth codes are replaced with placeholders in every log line. This means the log you read in the Logs window, and the one you copy out of it, are already anonymized — previously only the "Save error report" bundle was, which was the path people were least likely to take. The scrubbing also now catches forms it used to miss, including AWS_SECRET_ACCESS_KEY, LICENSE_KEY, PRIVATE_KEY, presigned storage URLs, and JWTs.
• Old error-report bundles are cleaned up. The newest five are kept. Profiler captures are left alone, since you asked for those explicitly.

[0.44.1] – 2026-07-20

Added

• You can now add your own Houdini install directories. TumbleTrove scans the standard locations (/opt, /Applications, Program Files), which missed builds kept anywhere else. Settings → Houdini → Install directories takes any number of extra folders — either a folder holding several builds, or a single build's install root — and builds found there are picked up with no particular naming required. Adding or removing a directory rescans immediately.

Fixed

• Houdini builds reached through a symlink are now detected with their real build number. SideFX's Linux installer creates a major.minor symlink (/opt/hfs22.0) pointing at the newest build in that line. TumbleTrove read the version off the folder name, so such an install registered as a bare series with no build — the version appeared in a project's Houdini list but reported "No builds available" and could not be selected. This was most visible when a line had only the symlink and no separate build folder alongside it. Versions are now read from the install itself, so these builds appear normally.
• An install and its symlink are no longer listed twice. /opt/hfs20.5 and /opt/hfs20.5.684 — and /Applications/Houdini/Current alongside its target on macOS — are the same install, but each showed up as its own entry under Installed. They now collapse to one.
• Installs without the HDK are now detected correctly. The Houdini Development Kit is an optional component in the SideFX launcher; an install missing it could report the wrong version on macOS.
• Launching a project no longer fails with "Access is denied. (os error 5)" on Windows. If the app was started by the installer's "launch when finished" option — and, less commonly, by Task Scheduler or some managed/antivirus wrappers — every project launch failed before Houdini started, even though the Houdini install was perfectly valid. The app asks Windows to let a Houdini session outlive it, and Windows refuses that request outright for an app started that way. The launch now retries without the request instead of failing. The only trade-off is that in that situation, quitting TumbleTrove may also close the Houdini sessions it started; starting the app from the Start menu avoids it entirely. If you hit this, you no longer need the "quit from the tray and relaunch" workaround.

[0.43.2] – 2026-07-19

Fixed

• Signing in now works on Linux when running the AppImage. Sign-in opens your browser and the result comes back to the app through a tumbletrove:// link. On Linux that link is normally claimed by the desktop entry the .deb/.rpm package installs — but an AppImage has no install step, so nothing ever claimed it. The browser had nowhere to send the result, and sign-in simply hung with no error shown. The app now claims the link itself on every start, so it also keeps working after you move, rename, or update the .AppImage. If you created a desktop entry by hand to work around this, you can delete it.
• Opening a sign-in link while the app is closed no longer loses the sign-in. If the app was not already running, the link that launched it was discarded before the app was ready to act on it, so sign-in never completed and had to be retried with the app already open.
• The Linux app no longer starts with a blank window on some systems. On NVIDIA's proprietary driver and some Wayland setups, the window drew nothing at all and the app looked frozen — previously only fixable by discovering the WEBKIT_DISABLE_DMABUF_RENDERER=1 environment variable. The AppImage now sets this itself. Setting the variable explicitly still overrides the app's choice.
• A sign-in link that fails to reach the app now says so in the log. A dropped sign-in callback was indistinguishable from an ordinary re-launch, so there was nothing to go on when reporting the problem. The log now records whether the link arrived, and explains what to check when it did not.

[0.43.1] – 2026-07-15

Fixed

• A project that sets OCIO (or another Houdini path variable) no longer crashes Houdini's Preferences on open. Setting a path-registered variable — OCIO, PYTHONPATH, HOUDINI_*_PATH — to "set" in a project's runtime environment produced a two-path value (Houdini's built-in default joined to the project's value) instead of replacing it. For OCIO on Houdini 22.0.367 this handed OpenColorIO two config files at once, and opening Main Preferences crashed with "could not read … .ocio profile". The bundled package manager (hpm 0.28.1) now writes "set" as a plain value that cleanly overwrites Houdini's own, so the project's config wins. (Verified against Houdini 21.0.729 and 22.0.367.)

[0.43.0] – 2026-07-14

Changed

• A downloaded update now asks you to install it, instead of hoping you notice. Updates download in the background, but the only prompt was a toast that vanished after 12 seconds, plus a small note in the status bar. Because the app normally sits in the tray with its window hidden, that toast was usually shown to a window nobody was looking at — so updates could sit downloaded and uninstalled for weeks. Now, once an update is ready, a dialog asks you to either Install and restart or choose Later. It waits for a moment when you are actually at the app — it never appears while the window is hidden in the tray, and never cuts across a project launch — and "Later" is respected for the rest of the session. Restarting takes a few seconds, and any Houdini sessions you have open keep running.

Fixed

• Restarting from the tray menu now installs a downloaded update. On Windows the tray's "Restart" restarted the app without running the pending installer, silently discarding the download — so anyone who restarts from the tray stayed on the old version indefinitely, no matter how many updates were downloaded. Tray restarts now apply a staged update on the way out.
• Installing an update no longer breaks the Remote Control API, and no longer resets your settings. Updates that carried a database schema change wiped the settings table on first launch. Most visibly this issued a brand-new Remote Control API token, so anything already holding the old one — the Claude Code MCP integration, the CLI, a script using TUMBLETROVE_REMOTE_TOKEN — started failing every call with "invalid or missing token" and kept failing until it was restarted. Because that reads like being signed out, the natural response was to sign in again, which did not help. The same wipe also silently switched the Remote Control API and Claude Code plugin toggles back on if you had turned them off, and discarded your window placement and per-package dev build profiles. Settings, including the token, now survive an update.
• A rejected Remote Control API token now says so, instead of looking like a sign-out. A 401 gave the same "invalid or missing token" message whether no token was sent or the token was wrong. The two need opposite fixes, so they now read differently: a missing token tells you where to copy one from, and a rejected token tells you the client is holding a stale token and needs restarting — and that you are not signed out.

[0.42.1] – 2026-07-14

Changed

• Switching to an organization you have no team access to now explains why the project list is empty. Organization projects are shared through teams, so a member who hasn't been assigned to one saw an empty list with no indication that the organization's projects existed at all — it looked identical to an organization with nothing in it. The empty state now names the organization, says its projects are shared through teams, and tells you to contact an organization admin to get assigned to one. Members who are on a team but lack Team Admin permission still get the (different) message about creating projects.
• Deleting a team now describes what actually happens to its projects. The confirmation said the team's projects would be removed and that the action could not be undone. In fact the projects are detached from the team rather than deleted: they stop appearing in the app, but they still exist and an organization admin can reassign them to another team. The confirmation now says so, and still lists exactly which projects are affected.

[0.42.0] – 2026-07-13

Fixed

• The app window no longer reopens on a different monitor after installing an update. On Windows, applying an update handed off to the installer in a way that skipped the normal save of the window's position, so the relaunched app restored a stale location — often a different monitor, or wherever the OS chose if that location no longer existed. The app now saves its position (and which monitor it is on) continuously and again right before an update installs, and on startup moves the window back onto its remembered monitor — including when the monitor arrangement has changed in the meantime.
• Activating a team member no longer shows them twice in the team's member list. Toggling an organization member onto a team could leave a duplicate row — one showing them enabled and a stale one still showing them disabled — until the team view was closed and reopened. Removing a member had the mirror problem: they disappeared from the list entirely (instead of returning as addable) until the next reopen. Both actions now update the list correctly in place.
• Personal projects no longer carry over between accounts on a shared machine. Projects created under one TumbleTrove login could show up in the project list after signing in with a different account — and a background sync could even upload the previous person's projects into the new account. Personal projects are now tied to the account that created them: after signing in you see only your own, syncing only touches your own, and switching accounts also clears the locally cached team projects and unpublished team-project drafts of the previous login. Your projects are not deleted by someone else logging in — they reappear when you sign back in. (On the first launch after this update, any existing projects are assigned to the account that is signed in at that moment, since older versions didn't record an owner.)
• Project env vars set to "append" or "prepend" now genuinely extend package-provided values for custom (studio) variables. Houdini only honors a package's env-var merge method when the variable is one of its own registered path variables (PYTHONPATH, HOUDINI_*_PATH, ...) or when the value is written in list form — for a custom variable written as a plain string, every later definition silently replaces the earlier one, whatever method was requested. The bundled package manager previously wrote plain strings, so a project override on a custom variable (e.g. a studio TT_* path) replaced the package's own value in every package that declared it, even with "append" selected. Env vars are now written in list form with Houdini's actual method names, so appends and prepends compose the way the project settings promise. (Verified against Houdini 21.0.688.)

Changed

• Package manager engine upgraded (bundled hpm 0.28.0). Three changes you may notice:
  • A broken package-registry configuration (bad URL or token) now fails with an "Invalid registry configuration" error at install/launch instead of the registry silently dropping out and packages later failing with a misleading "package not found".
  • Package downloads are verified against the registry's checksum before extraction — a corrupt or tampered archive now fails the install with a checksum mismatch instead of being installed.
  • Mistyped fields or sections in a package's hpm.toml are now parse errors naming the unknown field, instead of being silently ignored. Packages still published on the pre-0.16 manifest format ([env], [houdini], [native], [dev.env] tables) no longer install and need to be republished on the current format.

[0.41.2] – 2026-07-10

Fixed

• Houdini 22's new four-part version numbers are now handled correctly. Houdini 22 release-candidate builds carry a fourth number — for example 22.0.637.6, where the trailing .6 is the release-candidate iteration. The app previously assumed three-part version numbers, so these installs could be misidentified: a project pinned to 22.0.637 might fail to match the installed 22.0.637.6, such builds could sort into the wrong order, and the build id could be read as the release-candidate number instead of the actual build. Pinning, matching, and ordering now understand the four-part form — a 22.0.637 pin resolves an installed 22.0.637.6 while an exact match still wins over a release candidate — and the app never silently substitutes a different release candidate. (Three-part versions like 20.0.590 are unaffected.)

[0.41.1] – 2026-07-10

Added

• You can now pick which Houdini edition a project launches with. Each project card's launch group has a small edition dropdown (Automatic / Core / FX / Indie / Apprentice) next to the Play button. Pick one and that project launches that edition of Houdini from the same install — so a Core-licensed artist and an FX-licensed artist can open the same team project each with their own license. The choice is remembered per project on your machine only: it is never synced or shared with teammates, since which editions you're licensed for is personal to you. "Automatic" (the default) keeps the previous behaviour, so nothing changes until you choose an edition. If the edition you pick isn't installed, the launch fails with a clear message rather than quietly starting a different one.
• Headless hython runs are now protected by a memory watchdog. run_hython samples the interpreter's memory use every 2 seconds and kills the run if it exceeds a cap (max_memory_mb; defaults to half the machine's RAM, 0 disables). A runaway script -- like a long batch of APEX snippet compiles -- can no longer eat all your RAM and freeze the machine. Results now report mem_killed and peak_memory_mb so you can see how heavy a run actually was.

Changed

• Tooltips now wait a beat before appearing and are more compact. Hover hints across the app only show after the pointer rests on a control for about a quarter second, instead of popping up instantly as the cursor sweeps past — matching the feel of Houdini's own tooltips. The tooltip boxes are also smaller (tighter padding and text), so they take up less of the window.

Fixed

• The launch, profile, and download buttons on a project card now actually show their hover hints. The tooltips on those buttons (and the Profile dropdown's open-on-click) were wired up but silently dropped, so nothing appeared on hover. They now work, so you can tell the Dev, Profile, Launch, and Download buttons apart at a glance.
• Your manual project-card order no longer resets after an app update. The order you set by dragging personal project cards is stored locally, and a database migration bundled with some updates was rebuilding that table without carrying the saved order across — so after those updates your cards fell back to most-recently-used order. The order is now preserved through migrations. (Team project order was always kept on the server and was never affected.)

[0.40.0] – 2026-07-08

Added

• Project cards now show an "Edit project" hint on hover. Hovering a project card's name/details area surfaces a tooltip making it clear that clicking the card opens the editor — matching the existing hover hints on the launch and download buttons. The hint only appears for projects you can edit.

Changed

• Settings → Houdini now shows whether your SideFX account is already linked. The SideFX account card previously always read "Connect your SideFX account…" with a Link button, even when you were already connected — which was confusing. It now checks your link status when you open the tab: if you're linked it shows a "Connected" badge with your SideFX account and the date you linked it (mirroring the website), and if you're not it keeps the Link prompt, now with an "I've linked it — recheck" button so you can confirm without reopening Settings. Linking and unlinking still happen on the TumbleTrove website.

[0.39.0] – 2026-07-07

Added

• Copy a session's port and pid from its card. Each session card in the Sessions tab now has a copy button that puts the running Houdini's pid and RPC port on your clipboard, so you can paste them straight into a debugger, profiler, or bridge command without retyping. Only the values that exist are copied, and the button is hidden for a session that has neither.

Changed

• Session cards show the open scene next to the project name, and it stays live. A running session's title now reads Project (Scene) — e.g. SideFXrig2 (Noodle_Rig) — instead of replacing the title with the bare .hip filename, so both the project and the loaded asset/shot are visible at a glance. A session on an unsaved scene shows just the project name, and a custom name still overrides both. The open scene now also updates as you work: opening, saving, or starting a new scene is reflected on the card. (This requires the Houdini bridge package tumbletrove/tumbletrove 0.12.2 or newer, which now reports scene changes back to the app — earlier versions never did, so the scene could appear stuck on untitled.hip.)

[0.38.0] – 2026-07-07

Added

• Dev-package builds now know which Houdini versions you have installed. When a dev launch compiles a package whose build produces something per Houdini major (e.g. a native USD resolver built once per major), the desktop now tells the build which majors you have via the HPM_HOUDINI_MAJORS build variable — derived automatically from your discovered Houdini installations. A package that would otherwise try to build for every major in its release matrix (and fail on a machine that doesn't have them all installed) now builds only for the majors you actually have, with no per-machine configuration. If you set HPM_HOUDINI_MAJORS yourself in the app's environment, your value is used as-is. The Build tab logs which value was used. (Requires a package built with hpm 0.27.0 or newer, which reads this variable.)

[0.37.1] – 2026-07-07

Fixed

• The Logs window's Build tab now shows the dev-package build output reliably. When you switched from the Build tab to the App tab and back, the streamed build log could come up blank (just a cursor) until you moved the window; it now renders as soon as the tab is shown.

[0.37.0] – 2026-07-07

Added

• Project cards now keep a fixed order you can arrange by hand. Cards no longer reshuffle themselves when you launch or edit a project. Drag a card by its grip handle to set the order you want. On your personal list the order is yours alone; for an organization's team projects, admins set the order and everyone on the team sees it. Your existing lists keep their current order the first time you update, and newly created projects appear at the top. (Reordering is paused while a search filter is active.)

Fixed

• The Logs window's App tab now updates live. On macOS the tailed app log would stop refreshing and only catch up when you moved or resized the window; it now updates continuously while open.
• Launching a project no longer hides its Dev and Profile buttons. On a project with dev overrides, starting any launch used to replace the whole Dev / Profile / Launch button group with a single spinner, so the other buttons vanished until the launch finished. The buttons now stay put; the one you clicked shows its own spinner in place, and all three are disabled while a launch is in progress.

[0.36.3] – 2026-07-06

Fixed

• HDA edits made inside a dev session now save back to the package's workspace. When you dev-launch a project and edit one of its dev-overridden package's digital assets in Houdini (e.g. colour a node and Save Node Type), the change is now written back to that package's source folder instead of into a throwaway copy that the next launch overwrites. This works for packages that keep expanded HDA sources (otls-src/) and for packages that commit binary .hda files. It only ever updates an asset the package already tracks — it never creates a new file layout in your repo — and it now works on Windows, where per-session isolation previously did nothing at all (so edits silently vanished on the next launch). Previously this write-back was off unless an undocumented environment variable was set; it is now on for every dev session.

[0.36.2] – 2026-07-06

Fixed

• Restarting a Houdini session now brings it back the way it was. Restart now reopens the scene file the session had open instead of an empty scene, and reproduces the session's original dev-vs-production mode even after the desktop app itself was restarted while Houdini stayed open (previously such a session could come back in production mode). An unsaved/untitled scene still opens fresh.
• The Logs window now appears in the taskbar. On Windows the Logs window had no taskbar button or Alt-Tab entry, so once it slipped behind the main window there was no standard way to bring it back. It is now a normal standalone window you can find and re-focus.

[0.36.1] – 2026-07-05

Fixed

• Restarting a Houdini session no longer closes Houdini without relaunching it. On a dev-mode session, Restart killed the running Houdini and immediately relaunched — but the relaunch's package reinstall could race the still-closing Houdini, which on Windows kept its dev-package files locked, so the relaunch failed with a "being used by another process" error and nothing came back up. Restart now waits for the old Houdini to fully exit before relaunching. Production sessions and Linux/macOS were not affected.

[0.36.0] – 2026-07-04

Fixed

• Dev launches no longer fail with a "package in use" error just because another Houdini is open. When a project depended on a native package, every dev launch re-copied that package's files even when nothing had changed — and if a separate Houdini (a prior launch of the same or a sibling project) had those files loaded, Windows locked them and the launch failed with Package … is in use by another process … (Access is denied. (os error 5)). Launches now recognise an unchanged package and skip the re-copy entirely, so leaving another Houdini open no longer blocks a launch. Rebuilding a package still updates it; if a running Houdini genuinely holds the changed binary loaded, you'll still be asked to close it. Linux and macOS were never affected.
• The build console now shows the real error when a dev launch fails after building. Previously, if the dev-package build succeeded but the launch then failed downstream (for example the file-lock case above), the Build tab kept a green "Succeeded" badge while the status bar said "Launch failed" — leaving no error on the tab you were watching. The Build tab now flips to "Launch failed" and appends the underlying reason.

[0.35.0] – 2026-07-02

Added

• Run headless Houdini Python (hython) against a project. A new remote-control / MCP command, run_hython, runs a Python script or inline code under a project's Houdini hython interpreter without opening the GUI — with the project's fully-resolved package environment (and, on a dev run, a fresh dev-package build). It captures stdout/stderr and the exit code and enforces a timeout. This unblocks headless cooks, regression checks, and scene queries for Claude/automation, complementing the live-session sessions_exec_python.
• A new "houdini-scene-debug" Claude Code skill for debugging scenes and APEX graphs. The desktop app's bundled Claude Code plugin now ships a skill for diagnosing behavioural Houdini problems — a node that won't cook, a red cook error, a SOP producing wrong or empty geometry, or an APEX graph with cycles / unwired inputs — by driving a live Houdini session over its Python bridge. It complements the existing "houdini-dso-debug" skill, which stays focused on native C++/HDK debugging and profiling.
• Houdini-domain code-review checklists. The "houdini-dso-debug" skill now includes HDK C++, CUDA/GPU, and Houdini-Python review checklists (cook thread-safety, attribute-handle validity, GPU error/sync, callback performance) for reviewing native plugin code, not just debugging it.

Fixed

• Rebuilding a native plugin (DSO) for a dev-launched project no longer fails with a file-lock error on Windows. When a dev package shipped a native binary, launching it linked the compiled DLL straight from your workspace, so Houdini kept the file locked and the next rebuild failed with a linker sharing violation (LNK1104). Dev launches now use an independent copy of native packages, so you can rebuild against a stopped session and pick up the new binary on the next launch. Pure-Python and HDA packages are unaffected and still update live.

[0.34.2] – 2026-07-01

Internal cleanup only. (Release-pipeline fix — 0.34.0 and 0.34.1 failed to build; this is the first of the 0.34.x line to ship. The user-facing changes are listed under those versions below.)

[0.34.1] – 2026-07-01

Fixed

• The launch progress in the status bar now shows "Building..." while a dev launch compiles its packages. When you launched a project with its dev packages and those packages had to build first, the footer kept showing the previous step ("Checking for updates..." or "Preparing...") for the whole compile, which could be the longest part of the launch. It now shows "Building N package(s)..." while that happens, so the progress reflects what's actually going on.

[0.34.0] – 2026-07-01

Added

• A Logs window with tabs for the app log and dev-package builds. The window that used to just show dev-package build output is now a general Logs window with two tabs: App (a live tail of the desktop app's own log) and Build (the dev-package build console, unchanged). It still pops up automatically on the Build tab when a dev launch compiles packages, and you can keep it open to watch the app log.
• Save an anonymized error report. The Logs window has a "Save error report" button that bundles your recent app, build, and Houdini logs plus basic system info into a single zip, with personal details (your home folder, username, email addresses, and any token-like values) stripped out first — so it's safe to attach to a bug report. Sending reports to TumbleTrove directly is coming later; for now the button just writes the file and shows you where it landed.

Changed

• "Open logs" on an error now opens the Logs window instead of the folder. The "Open logs" button on an error message opens the new in-app Logs window (showing the app log right there) rather than just revealing the log folder in your file manager. You can still reveal the folder from inside that window.
• One refresh button instead of two on the project edit page. The project edit page's own refresh button (in its header) is gone — the refresh button in the status bar at the bottom of the window now covers it. That refresh still picks up freshly installed Houdini builds and a package's republished settings while the edit page stays open, so nothing is lost.

Fixed

• Newly gifted or licensed packages now appear when you add packages, without a restart. If a package was gifted or licensed to you (or your organization) while you had a project's edit page open, it wouldn't show up in the "Add Packages" picker until you restarted the app. The picker now refreshes its list each time you open it, so a just-received package is there right away.
• The build log now shows the output, even for a build that fails instantly. The console window that opens when you launch a dev project could come up empty — the build's output (including a fast failure like a missing pinned Houdini build) had already streamed past before the window finished opening, so you had to dig the log file out of ~/.tumbletrove/logs/build/ by hand. The console now replays the current build's output as soon as it appears, and again if you refocus it, so what you see matches the log on disk.

[0.33.0] – 2026-07-01

Added

• Choose a debug build for a dev launch, per project. Dev-overridden project rows gain a "Debug build (dev launches)" toggle in their right-click menu. When on, launching that project with dev packages compiles them with the debug build profile instead of release — so a package whose build emits debug-friendly binaries in debug (e.g. CMake RelWithDebInfo with symbols) gives you something you can actually step through, without editing the package. The choice is remembered per project, stays on this computer, and is honored no matter how you launch (in-app, tray, a coding agent over the API/MCP, or a restarted session). Default stays release, matching hpm build.

[0.32.0] – 2026-06-30

Added

• Profile launch — run a dev project's Houdini under a profiler. Dev-overridden project rows gain a gauge button beside the dev flask that launches Houdini under Nsight Systems (nsys) or Intel VTune, using the same dev environment. This is the right way to capture GPU/CUDA work (deformers, OpenCL): those interceptors only attach when they launch the process, so attaching to an already-running Houdini can't see them. The notification shows where the profiler report will be written. Coding agents can do the same over the API/MCP — launch_project now takes a profiler (nsys, vtune, or a custom wrapper command) and profiler_args, and returns the report path.
• The header title now opens the website. Clicking the "TumbleTrove" wordmark in the top-left of the launcher opens tumbletrove.com in your browser.
• One-click SideFX account link in Houdini settings. The Houdini settings tab now has a "SideFX account" section that explains that downloading Houdini builds and installing debug symbols need a linked SideFX account (yours, or your organization's) and links you straight to the website page to connect it — so you can set it up before you hit a "SideFX account not linked" failure.

Changed

• Launching a dev project now rebuilds its dev packages no matter how you launch it. Previously only the in-app dev-launch (the flask button) recompiled your dev-overridden packages before Houdini started; launching the same project from the tray, from a coding agent over the API/MCP, or by restarting a session skipped the build and loaded whatever binary was built last. All of these now recompile first, and a build failure stops the launch — so you can't accidentally run a stale binary. The build-console window still only opens for the in-app launch; the other paths record the build to the log file.

Fixed

• "Dev package build failed" when a build script pins a Python version. A dev launch compiles each dev-overridden package's build step first. If that step asked for a specific Python (or extra Python packages), the app ran it against whatever python happened to be on your system — so on a machine without a matching one it failed instantly with an empty build console. It now provisions the pinned interpreter the same way the hpm command line does, so the build runs as intended.
• A brief network hiccup no longer signs you out. When refreshing your session token failed because of a transient network or server problem, the app used to treat it as an expired session and sign you out. It now tells a genuine sign-in rejection (which still signs you out) apart from a temporary failure (which keeps your session), so a momentary connection blip doesn't interrupt your work.
• Coding agents stay connected through transient local-database hiccups. A momentary failure reading the app's local settings could cause it to generate a brand-new Remote Control API token, disconnecting any already-connected agent / MCP clients. Settings reads now fail safely instead of regenerating the token.
• Launching a project reports errors instead of silently dropping packages. If the app couldn't read a project's linked dev or local packages from its local database, it used to launch Houdini anyway without them. It now surfaces the error instead of starting a session that's missing dependencies.

[0.31.0] – 2026-06-25

Changed

• Package script menus now show only the scripts a package author marked for you, with friendly names. Right-click script menus (on a project or a dev-package card) previously listed every command in a package's hpm.toml, including build and packaging plumbing. They now surface only scripts the author gave a display name to, shown with that name and a tooltip describing what each one does — so you see "Launch My Tool" instead of cargo build or pytest. Packages published before this change won't list any scripts until their author republishes with the new labels.

Fixed

• Coding agents keep working when the desktop app restarts or updates. The Claude Code integration (the bundled MCP server) used to fail with auth/connection errors after the desktop app restarted — for example when it auto-updated — and you had to restart or resume Claude Code to recover. It now rides out the brief restart, picks up a regenerated Remote Control API token on its own, and refreshes its tool list automatically when the app updates to a version with different commands. No more restarting Claude Code after a desktop update.

[0.30.0] – 2026-06-24

Added

• Use local Houdini packages in personal projects. Personal projects now have a "Local packages" section where you can link a Houdini package folder on your machine that isn't published on TumbleTrove — anything you've downloaded or built elsewhere. Linked packages load every time you launch the project, alongside your registry packages. The link stays on this computer and does not sync to your other machines, so a local path can't break the same project when you open it elsewhere. (Personal projects only; team and organization projects are shared, so they aren't supported.)
• Coding agents can manage local packages over the API. The remote control API and its MCP tools gained list_local_packages, add_local_package, and remove_local_package, so an agent can link a local package folder into one of your personal projects (and it loads on the next launch) without the desktop UI.

[0.29.1] – 2026-06-22

Added

• Quick link to create a package. The Packages tab now has a "New package" button that opens the create-package page on tumbletrove.com in your browser. It targets the selected organization when you're browsing an org's packages, or your personal account otherwise.

[0.28.1] – 2026-06-16

Internal cleanup only.

[0.28.0] – 2026-06-12

Added

• Sessions are now labelled by their open scene. A running session's title now shows the filename of the .hip it has open (e.g. shot_010_anim.hip), with the project name kept as a subtitle, so two sessions of the same project can be told apart at a glance. Sessions on an unsaved scene, or that you've given a custom name, are unchanged. (Live scene names require the Houdini bridge package tumbletrove/tumbletrove 0.6.6+, which now reports scene changes back to the app.)
• Coding agents can now link dev package overrides over the API. The remote control API and its MCP tools gained add_dev_package, remove_dev_package, list_dev_packages, and list_all_dev_packages, so an agent can wire a package in your project to your local workspace checkout and immediately dev-launch against it — previously setting up an override was a desktop-UI-only step. The bundled houdini-dso-debug Claude Code skill now sets the override up itself instead of asking you to do it in the app.
• Coding agents can now install Houdini debug symbols over the API. A new sidefx_install_symbols remote command (and MCP tool) installs SideFX's debug symbols (Windows PDBs) into an installed Houdini build — the same action as the Install symbols button in Settings → Houdini. Because the symbols archive is a multi-GB download, the command starts the install in the background and returns a job id; a companion sidefx_install_symbols_status reports progress to completion or failure. The houdini-dso-debug skill uses it to make Houdini-internal stack frames readable without leaving the editor.

Changed

• Restarting or stopping a Houdini session now asks for confirmation. The Sessions tab's restart (circular arrow) icon was easy to mistake for the page's Refresh button, so people closed a running Houdini by accident. Restart and Stop on a running session now pop a confirmation dialog warning that Houdini will close and unsaved changes will be lost, and their tooltips now say "Restart Houdini" / "Stop Houdini". Restarting an already-exited session still relaunches immediately (nothing to lose).

Fixed

• Restarting to install an update now grabs the latest version first. If a newer release shipped while an update sat downloaded and waiting, clicking Restart used to install the older, already-downloaded build — and the app would immediately tell you yet another update was available. The restart now re-checks for a newer release and fetches it first, so you land on the newest version in a single step. If the re-check can't reach the server it installs the build you already downloaded, exactly as before.
• The Sessions tab "Focus window" button now works on Windows. Clicking the focus (target) icon on a running session previously did nothing on Windows — it reported "window focus is not yet supported on this platform". It now raises that session's Houdini window to the foreground (un-minimizing it if needed), the same as on macOS, so you can tell two otherwise-identical sessions apart. (Linux focus is still unsupported.)

[0.27.1] – 2026-06-12

Fixed

• The dev-build console no longer reopens on app startup. After a dev launch showed the build console window, it would reappear on its own the next time you opened TumbleTrove (its visible state was being remembered across launches). The build console is now treated as a transient window — it only appears when a dev launch actually builds something.

[0.27.0] – 2026-06-12

Added

• TT_DEBUG env var for launched Houdini. Every launch now sets TT_DEBUG in Houdini's environment — 1 on a dev launch (packages linked to your local workspace), 0 on a production launch — so HDA/Python code and launch scripts can branch on whether they're running a dev build. Like the other TT_* vars, an explicit project env-var override wins.
• Dev launches now build your dev packages first, with a build console. When you start a dev launch (the amber flask button) on a project whose dev-overridden packages declare a build step, TumbleTrove now compiles them before Houdini starts — so Houdini loads a freshly-built plugin instead of a stale one — and opens a terminal window streaming the build output live. It runs the package's standard build (the release profile, matching hpm build), so set your package's build to emit debug-friendly binaries (e.g. CMake RelWithDebInfo) if you're debugging. If a build fails, Houdini isn't launched and the console stays open showing the error. Packages with nothing to compile (pure HDA/Python) launch exactly as before. (This applies to the in-app dev launch; the remote control API's launch is unchanged and does not build.)
• New Claude Code skill for debugging custom Houdini plugins. The bundled tumbletrove-desktop Claude Code plugin now ships a houdini-dso-debug skill alongside hpm-manifest. It walks a coding agent through a native debug/profile session against a Houdini the app launches: link your package as a dev override, build the DSO with debug symbols (and, on Windows, install Houdini's PDBs), launch a dev Houdini and find its process id and Python bridge over the remote API, attach VSCode / gdb / lldb to that process, then drive the running Houdini to reproduce the bug and bind your breakpoints. It covers the HDK build flags (including the Windows release-CRT rule), per-platform attach configs, and CPU profiling. Aimed at studios developing HDK plugins — custom C++ SOP/DOP/ROP operators and DSOs.

[0.26.0] – 2026-06-11

Added

• Projects with dev package overrides now have a separate dev launch. When a project has one or more packages linked to a local dev override, its row shows two launch buttons: the main jade Play launches with the published registry versions of every package (a clean production launch), and a new amber flask button beside it launches with your dev overrides linked to your local workspace. Previously a project with overrides always launched in dev mode, with no way to quickly check the production versions; now the default launch is the published build and dev is an explicit, one-click opt-in. Projects without any dev overrides are unchanged — they keep the single Play button. (The tray quick-launch continues to use dev overrides.)
• The remote control API and its MCP tools can now launch projects in either mode. A new launch_project tool launches a project's Houdini and accepts a use_dev_overrides flag (defaults to a production launch), and sessions_restart now reproduces the mode the session was originally launched in (a dev session restarts as dev, a production session as production) or takes an explicit use_dev_overrides to override — giving automation the same dev/production distinction as the in-app buttons.
• Install Houdini debug symbols on Windows. For HDK/plugin debugging, you can now add SideFX's debug symbols (PDBs) to a Windows Houdini install: tick Install debug symbols in the Install Houdini dialog to add them right after installing, or use the Install symbols action next to an installed version in Settings → Houdini to add them after the fact. Symbols are a separate multi-GB download from SideFX that's extracted into the install, so it works regardless of how Houdini was installed. (Linux already ships symbols; macOS has none to install.)

[0.25.1] – 2026-06-10

Fixed

• Installing a beta Houdini build no longer fails to load the build list. After 0.25.0 started listing beta builds, fetching them for a brand-new Houdini series (e.g. 22.0) failed with a "Failed to parse response" error, because the app required a Python version for every series and SideFX/the server reports none for a freshly-opened major. The app now tolerates a missing Python version, so beta build listing and install work for those series.
• Python package dependencies for Houdini 20.5 projects now resolve against the correct Python. Houdini 20.5's default build uses Python 3.11, but the app was building its dependency environment against Python 3.10, which could cause package install/import mismatches. It now uses Python 3.11 for 20.5.

[0.25.0] – 2026-06-10

Fixed

• Projects pinned to a beta Houdini version can now be launched and installed. Launching a project pinned to a pre-release series — e.g. Houdini 22.0, which currently ships only beta builds — failed with "SideFX has no builds listed for Houdini 22.0", because the build lookup only ever asked for production builds. The lookup now includes beta/daily builds, so the pinned build resolves and downloads.

Changed

• The Houdini version picker now offers beta builds, grouped by release type. Pre-release series that have only beta builds (like Houdini 22.0) now appear in the version dropdown, split into Beta and Production sections so it's clear which is which. Picking a series still defaults to its latest production build where one exists, falling back to the newest beta only for a series with no production build yet.

[0.24.1] – 2026-06-09

Fixed

• An organization's linked SideFX account now works for downloading Houdini. Launching a project (or picking a build in its settings) that needed a not-yet-installed Houdini version failed with "Link your SideFX account" even when your organization had a SideFX account linked on the dashboard — the download path only ever checked your personal link. Houdini build listing and downloads for an org project now use the organization's linked SideFX account, falling back to your personal link only when the org has none. Members no longer need to link their own SideFX account to download builds for an org they belong to.

[0.24.0] – 2026-06-09

Added

• Install a project's Houdini version straight from its settings. When a project is pinned to a Houdini build you don't have installed, the version picker now shows an Install button that downloads and installs that build in place — handed off to SideFX's Houdini Launcher when it's set up on your machine, otherwise a direct download — and the form re-scans your installs when it's done. No more leaving the project to go install the version by hand first.

Changed

• The Houdini version picker now lists builds available to download, not only the ones already installed. Previously, if you had no (or no matching) Houdini versions installed locally, a project's version dropdown could be empty. It now shows the full set of downloadable builds from SideFX alongside your local installs, so you can pin any version up front. Browsing that downloadable list needs a connected SideFX account: when it isn't linked, the picker now shows a clear Link SideFX prompt (opening the account page) instead of an empty list or a misleading "failed to retrieve versions" message, and a subtler link hint appears when only your local installs are showing.

[0.23.0] – 2026-06-02

Changed

• SideFX-backed features now use your own linked SideFX account. Browsing and downloading Houdini builds, and publishing a package to a SideFX storage entry, now run against the SideFX account you connect to TumbleTrove rather than a shared platform key. If you publish, you no longer need to register a custom SideFX OAuth app and paste client credentials — linking your account is enough, and a linked-account storage entry appears automatically in the release dialog's upload picker. Connect your account at tumbletrove.com/dashboard/account under Connected accounts.

Added

• Clear "Link SideFX" prompt when a SideFX-backed action needs your account. If you try to list or download a Houdini build, or publish to a SideFX storage entry, without a connected (or with an expired) SideFX account, the app now shows an actionable notification that opens the account page so you can link or re-link — instead of a generic error. A previously-linked account whose session has expired is recognised as a re-link prompt and no longer looks like a sign-out.

[0.22.2] – 2026-06-02

Fixed

• Upgrading from a much older version no longer crashes the app silently on launch. When a long-dormant install (e.g. a 0.9.x build) was updated in one jump, the local database was too old for the migration path and the app panicked before its window ever appeared — the log froze at the startup banner with no visible cause. The database is now self-healing: if it can't be opened or migrated (an unsupported version jump or genuine corruption), the old files are moved aside into a timestamped ~/.tumbletrove/recovery-<timestamp>/ folder (never deleted), a fresh database is created, and the app continues to start. Personal projects resync automatically once you sign in, and a notice explains that local state was reset. Your sign-in, logs, and downloaded packages are left untouched. Any panic that does occur is now written to the log file instead of being discarded, so future launch failures are diagnosable.
• Projects can no longer be saved pinned to a Houdini version without a build number. Picking only the major version (e.g. "20.5") in a project's settings left it pinned to an incomplete version with no specific build — which the backend can't resolve to an installation, so launching failed with "no installation found" while the project looked perfectly fine in the list. Selecting a major version now auto-pins the latest available build for that series, and a project pinned to a build-less version is flagged with an inline error and won't save (create) or auto-save (edit) until a build is chosen. Opening an existing project that was already in this broken state now auto-repairs it to the latest build when one is available.

[0.22.1] – 2026-06-02

Fixed

• A project env var set to "append" or "prepend" now actually extends a package-provided value instead of overriding it. Previously, when a package contributed an env var (e.g. PYTHONPATH, HOUDINI_PATH) through its [runtime] and your project set the same key to append or prepend, the package's value was silently replaced — append/prepend behaved like "set". Bundled hpm moves to 0.19.0, which combines the project override with the package value when generating Houdini's package.json (set still replaces; append/prepend extend), and the launcher no longer re-applies those package-owned keys into the spawn environment (which had been double-applying the value). Custom env vars whose key no package declares are unaffected. If you previously relied on append/prepend to clobber a package value, switch that key to "set".

[0.22.0] – 2026-06-01

Added

• The bundled Claude Code plugin now ships an hpm-manifest skill that helps you write, fix, and migrate a package's hpm.toml. When the tumbletrove-desktop Claude Code plugin is enabled, Claude Code gains a skill (also runnable as /tumbletrove-desktop:hpm-manifest) covering the current Manifest 2.0 schema — [package], [compat], [runtime], [python_dependencies], [scripts], [stage] — the hpm build/hpm pack release contract, the TumbleTrove conventions (TT_CLAUDE_PLUGINS for shipping Claude plugins from a package, the install_source dev/registry branch pattern), and the common gotchas (the exclusive Houdini upper-bound footgun where <22 disables the package on all of 22.x, native-binary range bounding, the Windows bare-python exit-9009 trap, .gitignore vs .hpmignore for shipping build artifacts, and migrating off the pre-0.16 [env]/[native] tables before hpm 0.20 drops them). The skill is embedded at build time, so its guidance matches the hpm version the app actually bundles.

Fixed

• Claude Code plugins shipped by a package (TT_CLAUDE_PLUGINS) can now actually be installed. The per-project marketplace previously pointed Claude Code at the plugins' on-disk package locations with absolute paths, which current Claude Code rejects at install — so package-shipped plugins never appeared. The launcher now builds the marketplace in an app-owned location and copies each plugin into it with the relative paths Claude Code requires, so enabling discovery (or registering the marketplace manually) makes the plugins installable. The marketplace lives outside your project folder, and deleting a project now also removes its marketplace registration instead of leaving it dangling.

[0.21.2] – 2026-06-01

Internal cleanup only.

[0.21.1] – 2026-05-29

Added

• Reverse HDA sync (opt-in): edits inside Houdini land back in the package workspace as expanded source. When you set TT_HDA_REVERSE_SYNC=1 in the desktop's environment before launching, saving an HDA inside the running Houdini session now triggers hotl -t to expand the binary back into the workspace's otls-src/<name>/ tree — so your in-Houdini iterations on a digital asset become diffable changes in the package's source repository instead of opaque binary updates. Loop prevention via per-package md5 + 5s TTL: a write the forward watcher just made doesn't bounce back as a reverse update, and vice versa. Default OFF for safety — the opt-in is via env var until a per-session UI toggle lands; ship it on a single shell session at a time while you trust it. Phase 3 deliberately omits a hard workspace-wins conflict policy (relies on hash-equality between hotl -l's output and Houdini's resave for the common idle-save case); a future iteration may add one if real-world workflow exposes edge cases.
• Workspace edits to a dev-overridden package now propagate into the live Houdini session. While a session is running with a dev-folder override, the desktop watches the workspace and re-syncs changed files into the session's staging dir as you save: Python, shelf tools, JSON, and the rest copy 1:1; expanded HDA sources under otls-src/<name>/ are re-collapsed into otls/<name>.hda via hotl -l, then the running Houdini is told to reload the binding via hou.hda.reloadFile(...) so the new definition takes effect without you clicking "Reload OTLs". The watcher only fires while at least one dev override is active; sessions without any dev overrides see no extra activity. hotl is resolved from the same Houdini install the session launched against (or HDA propagation is skipped if no hotl is present). The source-convention is workspace/otls-src/<name>/ → staging/otls/<name>.hda; authors opt out by not using a otls-src/ dir. Reverse direction (HDA changes inside Houdini back to the workspace) is not yet implemented — that's a planned follow-up.
• Concurrent Houdini sessions of the same project with dev-overridden packages no longer share an on-disk package tree. When you launch Houdini for a project that has at least one local-folder package override, each session now gets its own materialised copy of every Houdini package manifest plus the dev package's content tree, under ~/.tumbletrove/session-staging/<session-id>/. Two sessions of the same project can iterate on the same dev package's HDAs without stepping on each other's loaded definitions. Registry-installed packages still resolve through the shared CAS, so the copy cost is bounded to the dev packages alone. Stale per-session dirs from prior runs are cleaned up at desktop startup, after session recovery has identified which sessions are still live. Projects with no dev-linked packages are unaffected.

Changed

• Package env contributions move from [env] / [dev.env] to [runtime] with an install_source axis. Bundled hpm jumps from 0.15.0 to 0.18.0, which folded the prior two tables into a single [runtime] whose conditional values gate on when.install_source = "dev" (path-installed) or "registry" (registry-installed). The HDK build-tree pattern shipped in 0.20.0 ports cleanly to the new shape:

  [runtime]
  HOUDINI_DSO_PATH = { method = "prepend", value = [
    { when = { install_source = "dev" }, set = "$HPM_PACKAGE_ROOT/build/Release" }
  ] }

  The project edit form, the Claude Code marketplace writer, and the Refresh button all read [runtime] and select the matching install-source branch — the dev-overridden case still surfaces the build-tree path, the registry-installed case does not. Same UX as before, new manifest syntax. Branches that further gate on houdini / os / python are still skipped by the desktop's discovery surface — those axes lower at Houdini startup and can't be evaluated up-front.
• Pre-0.20 packages with [env] / [dev.env] / [houdini] / [native] keep working with a deprecation warning, no immediate rewrite needed. Bundled hpm 0.18.0 detects Manifest 1.x shapes on load and converts them to the current schema in-memory, so installs of already-published packages — including 0.20.0-era ones that used [dev.env] for HDK dev paths — keep working without a hard parse error. Authors are warned to migrate; the new hpm migrate CLI rewrites a pre-0.16 manifest to the current schema in place (with hpm.toml.bak backup; --stdout to preview, --check to gate CI). Read-side legacy support is scheduled for removal in hpm 0.20.

Fixed

• Newly gifted (or licensed) packages now appear in a project's "add package" picker after a Refresh — no app restart needed. The Refresh button refreshed organization libraries but never the personal library, so a package gifted to your personal account only showed up once the app re-fetched the library at startup. Refresh now refetches the personal user library too.
• hpm init default Houdini range is now ^21. Previously the desktop's "Create local package" flow scaffolded packages with min_version = "20.5" and no upper bound, which silently allowed installs on a future Houdini major even for packages shipping native binaries. Aligns with hpm's new default; pure-data packages can still widen the range explicitly after init.

[0.20.0] – 2026-05-27

Added

• [dev.env] contributions from dev-overridden packages now surface in the project edit form. When a package is overridden with a local-folder path, env entries declared under [dev.env] in the package's hpm.toml — for example HOUDINI_DSO_PATH = "$HPM_PACKAGE_ROOT/build/Release" for HDK plugin development — now appear in the project edit form alongside the regular [env] entries, so you can see and override them per project without round-tripping through the package manifest. Same-key entries from [dev.env] replace the matching [env] entry rather than stacking, matching hpm's install-time behaviour. Requires hpm ≥ 0.15.0 (bundled).

[0.19.1] – 2026-05-25

Changed

• Renaming a Houdini session pre-fills with the project name. Clicking the title in the Sessions tab now opens an input pre-populated with the name you were already seeing (the project name, when you hadn't set a custom one), so you can tweak it instead of retyping. Submitting a value that matches the project name exactly is treated the same as leaving it empty — it clears any custom override, so the session keeps tracking the project's real name if the project is later renamed.

[0.19.0] – 2026-05-25

Added

• Custom names for Houdini sessions. Each row in the Sessions tab is now click-to-rename — type a label like "shot 040 lighting" or "rig pass" and it replaces the project name in the header (the project name moves to a sub-label so you can still see it). Names are persisted in ~/.tumbletrove/sessions.json and survive a desktop restart and a session re-handshake. Agents can set or clear the same name through the new sessions_set_name Remote Control / MCP command (name: null or empty clears, names trim and cap at 120 chars).

[0.18.1] – 2026-05-22

Fixed

• Re-launching a project with a dev-folder override no longer fails on Windows. A project whose package was overridden with a local-folder path would launch fine the first time, but every subsequent launch failed before Houdini spawned with Cannot create a file when that file already exists. (os error 183). On Windows, hpm's "replace existing dev link" path was stripping the junction's reparse point but leaving the empty directory stub behind, so the immediate re-create hit ERROR_ALREADY_EXISTS. Fixed by bumping bundled hpm to 0.14.1 (junction::delete is now followed by std::fs::remove_dir). Unix was unaffected because remove_file on a symlink-to-dir removes the entry fully.
• Per-package license auto-provisioning works again. On every project launch, the desktop tries to provision a license for each of the project's packages against the embedded license server. The request body field carrying the user's TumbleTrove access token was named accessToken, but the license server (tumbletrove-licensing) had been deserializing it as apiToken (the operator's platform credential it forwards to api.tumbletrove.com). Every provision call was returning 422 Unprocessable Entity and being silently swallowed by the best-effort path, so seats were never checked out at launch. The desktop now sends the field under the name the server expects.
• Project-edit env-var conflict warnings are now accurate. Previously two packages both append-ing or prepend-ing to the same variable (e.g. PATH) were flagged as conflicting even though those operations compose cleanly into a single concatenated value. The amber "conflict" badge on a package row now appears only when two or more packages try to set the same key (the case where only one value can actually win), and flipping a row's method to append / prepend resolves the warning in real time. The same badge has been extended to the Custom Variables section: a custom row whose key is also declared by a selected package — or duplicated by another custom row — is now flagged, since the project's env-var wire shape can only carry one value per key (the package override wins, and duplicate custom rows collapse on save).

[0.18.0] – 2026-05-21

Added

• Two new package lifecycle hooks: tt_enable and tt_disable — light, per-toggle counterparts to the existing heavy, one-time tt_install / tt_uninstall. tt_disable fires on toggle-off (pre-sync, while files are still on disk) so a package author can stop a service or otherwise deactivate the package without HPM having to redo the heavy install on the next enable; tt_enable fires on toggle-on (post-sync, files freshly present) to start the service back up. A permanent removal still fires tt_disable followed by tt_uninstall, and a brand-new add fires tt_install followed by tt_enable — the four hooks compose cleanly. Project state at <project_dir>/.tt_install_state.json gains an enabled array so subsequent prepares can tell a toggle apart from a real add/remove; older state files read fine and the first prepare after upgrade treats every previously-installed package as "newly enabled" (so any declared tt_enable fires once).

Changed

• tt_uninstall no longer fires when a package is toggled off — only on permanent removal from the project. Authors who relied on tt_uninstall running during a disable should move that teardown into the new tt_disable hook. (tt_install similarly no longer re-fires on a re-enable; use tt_enable for activate-on-each-toggle behavior.)

Fixed

• First launch of a team project no longer fails for new users. Team projects shown in the launcher came directly from the API, but launching one required the local sync cache to already contain it (Launch reads the project's organization off the cached row to dispatch back through the freshness-checked launch path). On a brand-new sign-in, or right after creating a team project, the cache hadn't caught up yet and the first launch attempt would fail with "Shared project not found in cache" — retrying after the background sync ticked then worked. The team-projects list / create / update endpoints now mirror their result into the cache as they return, so Launch can resolve any project the UI just showed without waiting for the next sync tick.
• Per-package disable toggles on team projects survive publishing. Flipping a package off in a team project edit form is a local-only choice (the server doesn't carry disabled state to teammates), but until now publishing any other change — name, packages, env vars — would silently re-enable everything as a side-effect of clearing the draft. The toggle now persists across publishes, and a draft that only disables packages no longer shows a (misleading) "Publish" button, since there's nothing for the server to receive.

[0.17.0] – 2026-05-20

Removed

• Standalone-library installs are gone — packages live inside projects only. The Packages tab no longer exposes "Install standalone" / "Uninstall standalone" right-click actions, the "Update vX.Y.Z" pills, the toolbar "Update N" button, the package detail page's Standalone section, or the Add Local button. The auto-globalization side-effect during project prepare (which copied any TT_CLAUDE_PLUGINS-bearing package into a global library so its plugins followed you across project switches) is also removed — plugins are now visible to Claude Code only while a project that ships them is the most recently prepared one. On first launch after upgrading, the legacy ~/.tumbletrove/library/ directory and its tumbletrove-library entry in Claude Code's known_marketplaces.json are cleaned up automatically. Library-scoped dev-folder overrides (created via the removed "Link Dev Folder" button in the Standalone section) are dropped during the same migration; per-project dev links from each "Used in Projects" row are preserved unchanged.

Fixed

• Edits to a dev-folder package now reach a live Houdini session immediately. When a project's package was overridden with a local-folder path, TumbleTrove (via hpm) was snapshot-copying the folder contents into ~/.hpm/packages/_dev/<slug>@<ver>/ at install time, and Houdini was loading from the snapshot — so working-tree edits to .apex / .hda / .py / .shelf files never reached the running session without a manual copy. Dev-folder overrides now use hpm's new link-mode (hpm ≥ 0.14.0): the install is a symlink (Unix) or NTFS junction (Windows) pointing at the working tree, so edits land in the session as soon as the file is saved and Houdini re-reads it. The Houdini package descriptor also stops drifting from a deleted snapshot version after a reinstall, since there is only one source of truth.
• Package compatibility check no longer mis-reports identical Houdini majors. The Houdini version-range parser used major + minor/100 arithmetic, which sorted 20.5 and 20.50 differently and could mark a package "incompatible" with the version you actually had installed. Now uses proper semantic-version comparison so 20.5, 20.50, and 20.5.100 all compare correctly against a constraint like ">=20.5,<21.0".
• Launching a team project during a server outage no longer silently uses stale local data. When the freshness check against the server failed, the Launch / Install buttons would quietly fall through to whatever was last cached locally — potentially missing recent package or env-var changes the user expected. The launch now surfaces the server error so you know to retry once connectivity is back.

[0.16.0] – 2026-05-19

Added

• Drive Houdini from TumbleTrove — run Python in a launched session. Sessions on the TumbleTrove Houdini package (tumbletrove/tumbletrove ≥ 0.6.2) now expose a Python console right in the Sessions tab: pick a running session, type Python (or press Cmd/Ctrl+Enter), and it runs inside that live Houdini, returning stdout/stderr and the result (or the Houdini-side traceback). The same capability is available to local automation and AI agents through the Remote Control API / MCP server as sessions_exec_python and a general sessions_bridge_call (scene, nodes, parameters, viewport, APEX, and exec.python). Calls are gated by the session's per-session capability token and only reach sessions TumbleTrove itself launched.

Fixed

• Houdini sessions are no longer lost when you restart TumbleTrove. A running Houdini launched by TumbleTrove now automatically re-attaches to the Sessions tab after the app is restarted (or was briefly down) — it reconnects, keeps its project name, and stays manageable, instead of getting stuck "Unresponsive" or disappearing. Requires the TumbleTrove Houdini package tumbletrove/tumbletrove ≥ 0.6.3; with older packages Houdini is unaffected but won't auto-reconnect (unchanged from before).

[0.15.1] – 2026-05-19

Added

• Command-line and AI-agent control of the running app. The installer now bundles two helper programs alongside TumbleTrove Desktop: tumbletrove-desktop-cli (drive the app from shell scripts) and tumbletrove-desktop-mcp (a Model Context Protocol server so AI agents can operate the app). Both talk to the local Remote Control API and need its bearer token (Settings → General → Remote Control API, or the TUMBLETROVE_REMOTE_TOKEN environment variable). The MCP server exposes one tool per supported command, generated live from the running app so the tool list never drifts from what the app actually supports.
• Claude Code integration. If you have Claude Code installed, TumbleTrove now publishes a first-party tumbletrove-desktop Claude Code plugin — registering its marketplace and pre-enabling it — so agents in Claude Code can control the running app (projects, packages, Houdini installs, sessions). The first time, confirm it in Claude Code (/plugin → tumbletrove-desktop). On by default; toggle under Settings → General → "Control TumbleTrove from Claude Code" (turning it off removes it again). The connection stays on your machine and uses the Remote Control API's bearer token; regenerating that token keeps working without re-configuring Claude Code.

[0.14.0] – 2026-05-18

Added

• Remote Control API — drive TumbleTrove from scripts and tools on your machine. A local HTTP API (on by default, http://127.0.0.1:18925) lets local automation manage projects, packages, Houdini installs, sessions, your account, and settings — the same operations the app's UI performs. It's reachable only from this computer and only with a secret bearer token shown in Settings → General → Remote Control API, where you can also turn it off, copy the token/URL, or regenerate the token (which instantly revokes the old one). The token persists across restarts and changes only when you regenerate it. Toggling the feature takes effect immediately — no restart.

Fixed

• The main window no longer reopens too narrow after the minimum width was raised. The window remembers its last size between runs; a size saved before the 500px minimum landed (0.12.3) kept restoring the window narrower than allowed until you widened it by hand. The restored size is now clamped up to the current minimum on startup.

[0.13.0] – 2026-05-18

Added

• New Sessions tab — see and manage every Houdini that TumbleTrove launched. Each launched project now shows up as a live session with its project name, Houdini version, process id, uptime, loaded .hip, current activity, and a status pill (starting / running / unresponsive / bridge-unavailable / exited / crashed). Per-session actions: Focus the window, Kill, Restart, and Recover a crashed session. The list updates itself as sessions come and go — no manual refresh. Window focus is implemented on macOS; Windows and Linux show an honest "not yet supported" for that one action (everything else works on all platforms).
• "Connect" an externally-launched Houdini. A Houdini you started yourself (outside TumbleTrove) can be adopted into the Sessions list so it's tracked and manageable alongside the ones the app launched.
• Advisory crash recovery. If a session crashed, Recover surfaces the most recent autosave and opens it as a copy — it never overwrites or touches your real .hip. Recommendations are surfaced, never enacted automatically.

Changed

• Houdini now keeps running when you quit TumbleTrove. Launched Houdini processes are detached at spawn, so closing (or updating) the desktop app no longer risks taking your open Houdini sessions down with it. Session tracking is strictly best-effort: it can never block, delay, or alter a Houdini launch — if anything in the tracking layer fails, Houdini still starts exactly as before.
• Projects on the TumbleTrove Houdini package get an in-app session bridge. With tumbletrove/tumbletrove ≥ 0.6.2 installed, launched Houdini reports its loaded scene and activity back to the Sessions tab. On Windows this connection is not yet verified, so a Windows session may show "bridge unavailable" — Houdini itself is fully usable regardless; only the live scene/activity readout is affected.

[0.12.3] – 2026-05-18

Changed

• Package cards in the project edit form now show the package's display name instead of its creator/slug path. The human-readable title from your library (e.g. "NodePilot" rather than tumblehead/nodepilot) is used as the card heading; the full path is still available on hover. Dev/local packages that aren't in your library continue to show their path.
• The main window's minimum (and default) width is now 500px, up from 420px, giving list rows and the project edit form more breathing room without manual resizing.

Fixed

• A Houdini install through the SideFX Launcher that fails because the Launcher isn't signed in now tells you so. When TumbleTrove routes an install through SideFX's Houdini Launcher but the Launcher app isn't signed in to a SideFX account, the install used to fail with an unreadable ~40-line wall of command-line usage text. It now shows a single actionable message: open the Houdini Launcher, sign in to your SideFX account, then retry. Other Launcher install failures also surface the real error instead of the trailing usage dump.

[0.12.1] – 2026-05-15

Added

• The tray "Recent Projects" menu now includes team projects, not just personal ones. Launching a team project (from the app or the tray) records it as recently used, and it can be quick-launched straight from the tray with the same up-to-date sync and unpublished-draft handling as launching it in-app. Previously the tray only ever listed personal projects, so anyone working primarily out of team projects had an empty or stale Recent Projects list.

Changed

• The two-column Basic Information layout in the project edit form now kicks in at the default 420px window width instead of only when the window is dragged noticeably wider. Settings and image pickers sit side-by-side from the start; the Houdini-version / build select row wraps onto two lines when the column is narrow so it doesn't overflow.

Fixed

• Linking a local dev folder onto a team project no longer fails with "Unknown dev-override target". Dev overrides validated the target only against personal projects, so setting a local folder override on (or just opening) a team/shared project was rejected and its env vars were dropped. Team/shared projects are now accepted as override targets.
• Deleting the ~/.hpm package cache no longer leaves the app in a lying state. If you wipe ~/.hpm between sessions, on next launch TumbleTrove now reconciles its own records against what's actually on disk: team projects that were marked "packages ready" are flipped back to needing a prepare, and the Claude Code library marketplace is rebuilt from only the packages still present so it never points at deleted plugin folders. Standalone library packages whose pinned version vanished are automatically reinstalled after sign-in (these never showed up as "updates", so previously they'd never come back on their own). Launching a project whose packages couldn't be restored now warns you that Houdini started without its package environment instead of failing silently. A stale "synced" marker also no longer survives a failed background sync — a sync that errored stays flagged as not-synced instead of being silently flipped back to ready on the next refresh.

[0.11.2] – 2026-05-14

Changed

• Package cards in the project edit form now ellipsize the left side of the path instead of the right, so the package name stays visible when the row is narrow. Most rows in a project share the same creator prefix, so seeing …/nodepilot is more useful than tumblehead/nodep….
• The project edit form's Basic Information section now lays out as two columns — settings (name, description, Houdini version, team) on the left and banner / splash images on the right — when the window is wide enough. Drops back to a single column at the default 420px width, so the narrow layout is unchanged. The form itself also grows up to ~42rem (was ~32rem) before centering, so dragging the window wider actually uses the extra space instead of leaving empty margins.
• Scripts and hooks declared with python / requirements now run in a uv-managed venv. A package can now declare the table form of a [scripts] entry (e.g. [scripts.tt_setup] cmd = "python scripts/tt_setup.py", python = "3.11", requirements = ["PySide6>=6.6"]) and the desktop will prepare a content-addressable venv on demand, prepend its bin/Scripts directory to PATH, and export VIRTUAL_ENV before spawn. Applies uniformly to tt_* hooks, project scripts (right-click on a project), and package scripts (right-click in the Packages tab). Plain string entries are unchanged — they still spawn against the host PATH, which is what package authors should opt out of if they hit "Python was not found" on Windows.

[0.11.1] – 2026-05-14

Internal cleanup only.

[0.11.0] – 2026-05-14

Added

• Per-project dev-folder overrides. Each project (and your standalone library) now opts into its own dev-folder links independently — every package card in a project's edit form has a Link Dev Folder control that targets just that project. Project A can dev-test a local fork of a package while Project B keeps using the published version, with no cross-talk. Existing dev links carry forward at upgrade: personal-scope folders fan out to every personal project + the library, and org-scope folders fan to every project in that org. The package detail page's library dev-link is now folded into the Standalone section.
• Used in Projects panel on the package detail page. Every personal and team project that references a package now shows up in an inline list, with the pinned version and an Open button that reveals the install directory in your file manager. Pulls team projects from a cross-org rollup so the list shows up regardless of which scope you're currently in.

Changed

• Reorganized the package detail page. The read-only registry version list is replaced with a focused Standalone section that shows whether the package is installed in your standalone library, the version, an inline Update button when a newer release is available, and shortcuts to open or uninstall. Creator yank/delete admin controls move into the Creator section so destructive actions stay out of every viewer's path.
• Installing, uninstalling, or updating a standalone package now shows an in-progress status-bar notification (e.g. Installing creator/slug…) the moment you click the menu item, instead of staying silent until the operation finishes. Previously users couldn't tell whether the click had registered while the registry resolve and download were running.
• Status-bar notifications now pause their auto-dismiss timer while the cursor is over them — hover to keep reading, move away to let the toast clear on its own. Error toasts also stay on screen longer by default (30 seconds, up from 12) so there's more time to read a message or click Open logs before the toast disappears.
• Package cards in the project edit form now sit on the same surface tone as the cards on the Packages tab, and the dev-override tint is brighter so a linked dev folder stands out at a glance.

Fixed

• The Installed tab now correctly identifies which projects use each package. Packages added to a project via the picker are stored as creator/slug paths, but the matcher was comparing them against the bare slug returned by HPM — they never matched, so every installed package was flagged Unused and the "Used by:" line under each row was always empty. The "Remove package" confirmation dialog's "affected projects" list had the same bug and was also empty in practice. Both lookups now accept either form, mirroring HPM's own canonical-or-slug match.
• Modals fade in centered instead of zooming in from the top-left corner. The previous animation felt off when the dialog opened over a busy UI.

[0.10.0] – 2026-05-14

Added

• Packages that ship Claude Code plugins now register them in your standalone library automatically when you install the package into a project — the plugins follow you across project switches without a manual right-click. Honors Settings → General → Register marketplaces with Claude Code: with the toggle off, neither the per-project marketplace nor the standalone library is auto-registered. A status-bar notification lists what was added.

Changed

• Renamed the Packages-tab right-click action from "Add to / Remove from Claude Code library" to "Install standalone" / "Uninstall standalone". The library is a project-less HPM install — useful for any package you want available outside a project, not just Claude Code plugins — so the menu copy now matches what the action actually does.
• The status-bar refresh button now refreshes all launcher data — projects, teams, team projects, packages, dev packages, standalone library (with update check), installed packages, Houdini installations, and your organization list — in addition to checking for app updates. Previously it only checked for app updates and, in org scope, re-synced shared projects; data shown on other tabs only refreshed when you re-entered the tab.

Fixed

• Private packages owned by your organization now install correctly when added to a project. The desktop used to query the package registry without sending your session, so the API returned a 404 for any private package — the desktop then silently dropped it from the generated project manifest and proceeded to install the remaining packages. Symptoms: an org member adds their org's private package to a project, the prepare/launch step looks like it succeeds, but Houdini comes up without the plugin loaded. The desktop now sends your bearer token on every registry query and through the install path, so the registry returns private packages you're entitled to see (creator-scope members, gift recipients, admins).
• Long dropdowns (package version picker, Houdini version/build pickers) now scroll inside the popover instead of overflowing past the top of the window when the list is taller than the available pane. Previously, picking an older package version on a short window left the earliest entries inaccessible.
• The selected organization scope and active tab now survive a restart or app update. Both were already saved locally, but the post-auth reset that runs on sign-out was also firing once on every cold boot — during the brief window before the saved session was validated — overwriting the persisted org scope with "personal". Switching to personal also caused the "Teams" tab to fall back to "Projects" because the tab no longer existed in the current scope. The reset now waits for the auth check to actually resolve.
• Several reliability fixes to the embedded license server that affect long-running sessions and cache-mode deployments. A freshly-renewed seat could be silently dropped by the staleness reaper if a heartbeat arrived in the brief window between the reaper's snapshot and its delete pass. Re-provisioning a license effectively double-counted the seat pool until orphaned leases timed out, so a studio re-issuing a license at a fresh jti could see false NoSeatsAvailable denials for ~5 minutes. Heartbeat responses and /v1/status responses now agree on the seat count (heartbeat previously omitted batch reservations, so a client watching heartbeat thought the pool had more headroom than it did). Caches no longer keep granting seats after the upstream license has been revoked. Background tasks (reaper, CRL sync, cache renewal) now exit cleanly when the desktop shuts the license server down, fixing a slow leak in long-lived sessions.

[0.9.99] – 2026-05-13

Fixed

• Houdini plugins now reliably see the licenses you've provisioned, even after a prior TumbleTrove Desktop crash left a leftover server process. The launcher used to bump to the next port and broadcast a duplicate mDNS record, so plugins on the same machine would sometimes attach to the stale server and miss recent provisioning. The desktop now binds the canonical license port deterministically and either attaches to a healthy existing server it finds there or reports a clear error if an unrelated process is squatting the port.
• Project auto-save no longer surfaces a "Failed to parse response: unknown variant WINDOWS" status-bar error on Windows. The website's /v1/user/projects endpoint emits "platform": "WINDOWS" (uppercase, matching the registry's convention), but the desktop's response parser only accepted lowercase — a single uppercase row would fail the whole response parse, so personal-project edits looked saved locally but never reached the server. The desktop now accepts platform values in either case.

[0.9.98] – 2026-05-12

Fixed

• Sign-in failures (cancelled provider login, expired session, account-link conflict, etc.) now show a clear error message immediately. Previously the desktop sat on a 5-minute spinner before timing out with a generic "Authentication timed out" — the website's OAuth bridge page was rendering an error card in the browser but never firing a tumbletrove:// deep link back to the desktop, so the app had no signal anything had gone wrong. Both sides now exchange a structured ?error=<code>&error_description=<message> redirect on failure, and the desktop maps the code to a real user-facing message.

[0.9.97] – 2026-05-12

Added

• The release dialog now shows an Open storage settings button when no upload destination is configured, deep-linking to your TumbleTrove storage page (scoped to the current org when releasing under an org). Previously the empty-state copy told you to "add a bucket on TumbleTrove" but offered no direct way to get there.

Fixed

• Cleaning up an unused Houdini installation now also deregisters it from the Houdini Launcher. Previously TumbleTrove deleted the files on disk but left the entry in the Launcher's "Houdini Versions" list, so clicking Launch on a cleaned-up version failed with "houdini.exe is missing". The desktop now calls houdini_installer uninstall for each path inside the same elevation prompt that performs the forced delete. Pre-existing broken entries already in the Launcher need to be removed once via the Launcher's per-row gear menu (or Windows Add/Remove Programs); this fix prevents new ones from accumulating.

[0.9.96] – 2026-05-11

Fixed

• Installing a package on Windows no longer silently unpacks the Linux build. The TumbleTrove registry tags builds with short OS strings (WINDOWS / LINUX / MACOS), but HPM was matching against the canonical long form (windows-x86_64, etc.) with strict equality and then falling back to the first build in the array when nothing matched. Concrete impact: tumblerig@1.3.15 on a Windows host unpacked the Linux .so artifacts because Linux happened to be first in builds[], and Houdini then failed to load the plugins with no clear error. The bundled HPM (0.11.2) now matches both forms case-insensitively, treats platform: null / "universal" as a universal fallback, and surfaces a clear "no compatible build" error instead of installing the wrong one. Re-install any package whose plugins failed to load after a previous attempt.

[0.9.95] – 2026-05-11

Fixed

• Clicking Install on a team project with unpublished changes now applies the draft, matching Launch. Previously Install ran against the published state and silently missed any draft Houdini-version pin, package adds/removes, or tt_install / tt_uninstall hooks the user wanted to test — which made the draft look like it wasn't being applied even though the Launch path was already draft-aware. Both buttons now resolve the project through the same draft-overlay path.
• The TT_PROJECT_SCOPE env var passed to Houdini and tt_* hook scripts now distinguishes the three real cases — personal, organization, team — instead of folding org-but-not-team projects in with personal. Hook scripts that branched on this value can now tell whether they're running under an org-scoped project shared with a team versus an org-scoped project a single user owns.

[0.9.94] – 2026-05-08

Fixed

• Project list ordering is now stable across background refreshes. Personal projects sort by lastUsed and team projects by updatedAt, but ties (e.g. several never-opened projects, all at epoch 0) used to inherit whatever order the DB / API returned on each fetch — so any background sync event would silently reshuffle them. Ties are now broken on id, so the list keeps its order until the underlying signal actually changes. (Reported on Windows 11, but the cause is platform-independent.)
• Releasing a package to a SideFX-typed storage entry now works on Windows when the package contains subdirectories. Archives produced by hpm pack on Windows wrote ZIP entry names with backslash separators (e.g. config\.gitkeep instead of config/.gitkeep), which violates the ZIP spec and is rejected by SideFX hpackage with "…is not permitted (absolute/relative/backslash)". The desktop now bundles HPM 0.11.1, which packs spec-compliant / separators on every platform. Re-pack and re-release any in-flight package built on Windows with an earlier desktop version.

[0.9.93] – 2026-05-06

Internal cleanup only.

[0.9.92] – 2026-05-06

Added

• Project banner and splash images are now separate fields. The banner remains the wide 5:1 strip rendered behind the project title in the projects list (with negative space on the left for the title overlay), while the new Splash Image picker accepts a 16:9 hero image that Houdini shows at startup. The two surfaces have very different shape requirements, and one image trying to serve both meant compromising on either the title overlay or the splash composition. Existing projects keep working unchanged: when no dedicated splash is uploaded, the launcher falls back to the banner image at Houdini launch, so a custom splash is only needed if you want a different image at startup than in the projects list.
• The project edit form's header now has a Refresh button (top-right). It re-scans installed Houdini builds and re-fetches published version data, so a Houdini you just installed shows up in the dropdown without an app restart. It also re-runs the package env-var discovery, so a republished package's new declarations surface in the form. Replaces the previous "quit and relaunch the desktop to pick up the new version" workaround.
• Per-package version lists in the package detail view now mark which version (if any) is currently in your Claude Code library with an installed chip. Previously you had to inspect ~/.tumbletrove/library/ on disk to answer "is this version on my machine?".

Changed

• The Update vX.Y.Z pill on Packages-tab cards is now clickable. Clicking it runs the same library update as the right-click menu's Update to vX.Y.Z entry — the most prominent visual signal for "an update is available" is now also the affordance, instead of being a label that did nothing on click. Per-pill spinner during the update; other pills disable while one is in flight to prevent simultaneous updates competing for the marketplace registration step.
• Hovering the toolbar Update (N) button now shows a tooltip listing the packages it'll touch and the versions they'll move to, so the count isn't opaque when you have several packages with pending updates.

[0.9.91] – 2026-05-05

Added

• Houdini launches now expose a TT_* context block in the process environment so HDA/Python scripts can read who/what is running without round-tripping back through the API: TT_PROJECT_NAME, TT_PROJECT_DIR, TT_HOUDINI_VERSION, TT_PROJECT_SCOPE (personal/team), TT_ORGANIZATION_SLUG (team projects only), TT_USER_EMAIL, TT_USER_NAME. The resolved set (with project overrides applied) is also forwarded to each tt_prepare hook's environment, so context-aware hooks (e.g. fetching a per-user secret) don't have to re-derive what the desktop already knows. A project that explicitly sets one of these as an env-var override keeps its value, so testing with a fake user/project name still works.

Changed

• Editing a team is now a single page. The previous flow split team metadata (name, description, private toggle) into a separate "Edit Team" form behind the row's three-dot menu while clicking the row opened a different "Members" page — easy to miss that the form even existed. Clicking a team now opens one detail page that shows both: settings at the top (auto-saved on a 1.5s debounce, matching how project edits already behave) and the member roster below. The redundant Edit menu item is gone; the "New" button still opens a dedicated create form.
• Team cards now show a stacked row of member avatars (up to 5, with a +N chip when the team has more) instead of just a numeric member count, so you can pick out a team by who's in it at a glance. Backed by the new sampleMembers field on GET /v1/organizations/{slug}/teams — no extra round-trips per team. Older teams without member data fall back to the previous count badge.

Fixed

• The Packages tab now refreshes its "newer version available" check every time you visit the tab, instead of only once per app launch. Previously the check ran exactly once at sign-in — so if a creator published a new version while the desktop was already open, the per-row Update vX.Y.Z badge and context-menu Update to vX.Y.Z entry never appeared until you restarted, and right-clicking → Open silently ran whatever stale version was already on disk. The refresh is throttled to once per 30 seconds so rapid tab-bouncing doesn't fan out on the registry.
• Launch-activity events (POST /v1/activity/launch) are recorded again. The server now requires a platform field (one of linux/windows/macos) and the desktop wasn't sending it, so every launch returned 422 Validation failed and was silently dropped — meaning org "Recent activity" feeds and per-user launch counts have been blank since the API tightened. The desktop now sends std::env::consts::OS (which already emits the exact lowercase strings the API enum accepts).
• Releasing a package to a SideFX-typed storage entry now accepts hpm.toml [houdini] versions in any segment count. The previous fix in v0.9.88 split multi-conjunct enable strings but didn't touch the version operands themselves; users who wrote min_version = "21" (single segment) or min_version = "21.0.5" (three) hit "must declare a strict minimum Houdini version" because hpackage's per-clause regex requires exactly X.Y. The desktop now pads single-segment versions to X.0 and trims three-plus-segment versions to X.Y while rewriting the JSON for hpackage, in both string-form and object-form enable clauses.

[0.9.90] – 2026-05-05

Internal cleanup only. — Republish of v0.9.89. The previous tag's CI check workflow failed on a stale Vitest snapshot (src/lib/__tests__/__snapshots__/tauri-commands.test.ts.snap) — the remote-session-compat feat from v0.9.88's tail added two CMD constants without updating the alphabetic snapshot. Snapshot refreshed; v0.9.89's user-facing fixes (Windows package-script @ quoting, remote-session compatibility toggle) ship here.

[0.9.89] – 2026-05-05

Added

• New default-on Settings toggle "Remote session compatibility" (under Settings → General → Houdini Launch). When enabled, every Houdini launch gets HOUDINI_OCL_DEVICETYPE=GPU and HOUDINI_USE_HFS_OCL=0 injected into its environment, which prevents Houdini from hanging when started inside a remote-desktop session (Parsec, RDP, etc.). Applies to both personal and team projects. A project that explicitly sets either variable in its env-var overrides keeps its value, so per-project tweaks still win.

Fixed

• Running a package script on Windows no longer fails with '"C:\…\<slug>@<version>\…\<exe>"' is not recognized as an internal or external command for scripts written the way HPM's docs recommend ("\"$HPM_PACKAGE_ROOT/plugin/bin/tool.exe\" args"). cmd.exe's cmd /C parser strips the outer quote pair only when the inner command has no special characters between its quotes — and @ is one of those special characters, which is unavoidable because HPM's content-addressable storage always writes packages to <slug>@<version>/. The desktop now parses the script string itself (POSIX-style argv splitting with "…" / '…' quotes, \ escapes, and $VAR / ${VAR} expansion against the script's environment) and spawns the program directly via CreateProcessW, sidestepping cmd.exe entirely. Scripts that genuinely need shell features (pipes, &&, redirections, etc.) keep using cmd /C / sh -c as before. Affects all three Windows script paths — package scripts (Packages tab right-click), project scripts (per-project actions), and tt_* lifecycle hooks (tt_setup, tt_install, tt_uninstall, tt_prepare).

[0.9.88] – 2026-05-05

Fixed

• Project launch no longer fails on a clean Windows install with Failed to install packages … Python dependency resolution failed: No interpreter found in virtual environments, managed installations, search path, or registry. The bundled UV resolver needed a Python interpreter and didn't have one to fall back on; HPM now downloads a managed CPython on first launch (kept under ~/.hpm/uv-python/ for clean uninstall) before invoking uv pip compile or uv venv.
• Project launch on Houdini 22 now resolves Python 3.13 wheels instead of whatever Python version a dependency package's [houdini].min_version happened to declare. Previously a Houdini-22 project consuming a min_version = "21.0" dependency would silently get a 3.11 venv whose C-extension wheels (pymongo, watchdog, …) crashed on import inside Houdini 22's interpreter. The project's own Houdini version is now authoritative for venv ABI selection.
• Releasing a package to a SideFX-typed storage entry now matches the official hpackage CLI's author upload flow end-to-end. Previously the desktop went straight to hpack.start_upload, which SideFX rejects with Invalid package name '<slug>' for any name not already reserved by the caller — so first-time releases for a fresh package never worked. The desktop now (1) reserves the package name on every upload (idempotent — 422s on existing packages are ignored), (2) validates the Houdini-native package.json against hpackage's schema before any network call so misconfigurations surface as readable errors instead of opaque 422 bodies, (3) splits single-string enable conjuncts into the dict form hpackage actually parses (a multi-condition houdini_version >= 'X' and houdini_version <= 'Y' was being rejected silently), and (4) reshapes the flat hpm pack archive into hpackage's expected layout ({slug}.json at zip root, content under {slug}/) so Houdini's hpath resolves to actual files when the archive is extracted.
• HPM users can now install packages hosted on SideFX without SHA-256 / signature verification failures. The repack step above mutates the archive bytes, which means the SHA-256 and Ed25519 signature hpm pack computed for the flat archive no longer match what's served at sidefx.com. The desktop now recomputes both over the repacked bytes (using the same signing key from ~/.hpm/signing-key.bin, so packages stay signed) and records them on the registry version, so the integrity check on install matches the actual download.

[0.9.87] – 2026-05-05

Internal cleanup only. — Aggressive cleanup pass: dropped the UserLicense flatten layer (was inventing licenseType/seats/expiresAt fields the API never populated and no consumer ever read), simplified license_list_user to return package paths directly, and tightened the TeamProject wire shape — team_id removed end-to-end (no consumer reads it; teamSlug is the canonical routing key) and teamName/teamSlug are now honest Option<String> instead of String defaulting to "". Schema bump v23→v24 drops the now-unused team_id column from shared_project_cache; the cache rebuilds on next launch.

[0.9.86] – 2026-05-05

Internal cleanup only. — Republish of the v0.9.84 publish-error fix. v0.9.85 fixed the Cargo path issue from v0.9.84 but tripped over a test fixture that still constructed TeamProject.team_id as a bare String after the field was made Option<String> — cargo clippy --all-targets caught it in CI.

[0.9.85] – 2026-05-05

Internal cleanup only. — Republish of the v0.9.84 publish-error fix. The v0.9.84 release build failed at cargo clippy because that release also bundled a botched Cargo.toml path change (the licensing crate was retargeted at a sibling rename that doesn't exist on CI), so the auto-updater never saw v0.9.84.

[0.9.84] – 2026-05-05

Fixed

• Publish-error toasts now show the offending package path again. After the platform's slug-only /v1/* migration, the per-package blocker field renamed from packageId to path, and the desktop was still reading the old field — so unpublishable team projects surfaced as "unknown package is not published" instead of naming the actual package.

[0.9.83] – 2026-05-05

Internal cleanup only. — Republish of the slug-only IPC refactor after the 0.9.82 typecheck gate failure (test fixtures and a PackagesView call site still referenced the dropped Organization.id field, so 0.9.82 produced no published artifact).

[0.9.82] – 2026-05-05

Changed

• Aligned with the platform API's slug-only /v1/* contract. Internal cuids (organization, creator, package) never appear in URLs, request bodies, or response bodies — the desktop now uses the organization slug as the canonical scope identifier on both sides of the IPC boundary, mirroring the existing path-only package contract. Storage, creator-package, dev-package, and shared-project-sync calls now pass organization=<slug> instead of organizationId=<cuid>. Older builds will fail to fetch storage entries, list org packages, and sync team projects against the updated backend, so the auto-updater will roll users forward.
• Local-data note for users with org-tagged dev packages or local org projects: the v22→v23 schema migration renames the organization_id column to organization_slug and drops any legacy cuid value (the desktop has no way to map a stored cuid back to a slug without a server round-trip). Personal projects are unaffected. Team projects re-populate from the next /teams/my-projects sync, so the impact is normally a single quiet refresh after upgrade. Dev-package overrides that were tagged to an org need to be re-added under the right scope; standalone personal-scope dev overrides survive untouched.

[0.9.81] – 2026-05-04

Fixed

• Releasing a package to a SideFX-typed storage entry no longer fails with SideFX: In the package json, shorten '0.1.0' to '0.1'. SideFX's hpackage catalog only accepts MAJOR.MINOR versions, but hpm-package embeds the full SemVer (e.g. 0.1.0) in the Houdini-native package.json it injects at archive root. The desktop now strips the patch component when posting metadata to hpack.start_upload and uses the same shortened form in the resulting hpackage/download/{slug}/{version}.zip URL — the registry record on TumbleTrove still keeps the full SemVer.
• Publishing a team project that fails server-side validation now surfaces the per-package blocker reason even when the server couldn't resolve a slug for the rejected package (NOT_FOUND blockers). The desktop's response deserializer was rejecting slug: null and dropping the typed details, so users only saw a generic "Publish failed" toast instead of the actual per-package explanation.

Changed

• Aligned with the platform API and tumbletrove-license-server v0.6.0 path-only contract: every package-scoped /v1/* route uses creator/slug paths, package-shaped responses carry a single path (or packagePath for license payloads) instead of separate id/slug/creatorSlug fields, and the embedded license server's /v1/provision and /v1/status use packagePath. No user-visible behaviour change in the desktop itself; older builds will fail to register releases and provision licenses against the updated backend, so the auto-updater will roll users forward.

[0.9.80] – 2026-05-01

Fixed

• Re-publishes the v0.9.79 fixes (see below). The v0.9.79 release build failed at cargo check --tests (a test-only struct literal was missing two fields added in v0.9.78), so the auto-updater never received the v0.9.79 set — v0.9.80 ships the same changes plus the test-helper fix.

[0.9.79] – 2026-05-01

Fixed

• The project edit form now surfaces a package's environment-variable rows immediately after you add it, instead of staying blank until the project has been prepared/installed. Env-var discovery used to read [env] from each package's hpm.toml in the local HPM cache only, so freshly-picked packages had nothing to render and the card looked like it had no overrides to configure. The desktop now falls back to fetching the manifest from the registry (which transparently downloads + caches the package) when the cache doesn't already have it, so the chevron and override rows appear as soon as the picker confirms.
• Releasing a package to a SideFX-typed storage entry no longer fails with <slug>.json missing 'version'. The desktop was reading the version field from the wrong location in the Houdini-native package.json that hpm-package injects at archive root — uploads to SideFX hpackage have been broken since the destination was re-added in v0.9.76.
• The Packages tab and the project package picker now show the correct set of installable packages when scoped to an organization. Previously the desktop drew that list from the admin-only license-assignment endpoint, which omitted platform-wide default packages and any individually-assigned licenses — so members would see "no packages" or a partial list even when entitlements existed. The desktop now reads the organization's per-member entitlement endpoint instead, which returns org-wide purchases, the org creator's own published packages, your own assigned licenses from the org, and the platform default packages — the same coverage personal scope already had.
• Personal projects and creator-owned packages no longer silently truncate at 100. The list-fetching paths (/v1/user/projects for project sync, /v1/creator/packages for personal and org creator package lists) now page through the entire result set instead of taking only the first page; users with large project counts or large package catalogs no longer "lose" entries past the cap.
• Publishing a team project that contains a package other team members can't access (unpublished, private outside the org, or unlicensed) now surfaces a precise per-package reason instead of a generic "publish failed" message. Validation runs server-side on every save, so the desktop also catches the case where a package was unpublished or had its license revoked between your last fetch and clicking Publish — previously the client-side check used cached data and could miss this.

Changed

• The team-membership picker (Teams tab → click a team → Members) now loads in a single round trip instead of two. No visible UI change, but member list paint should feel tighter on slow connections.

The v22 database migration runs automatically on first launch. It rewrites ~/.tumbletrove/projects.db from a JSON dump (the previous DB state is preserved at ~/.tumbletrove/pre-migration-backup-*.json), drops two columns no longer used by the desktop, and scrubs a small set of stale environment-variable method values left by older builds. No user-facing behaviour changes.

[0.9.78] – 2026-04-30

Fixed

• Re-publishes the v0.9.77 fixes (see below). The v0.9.77 release build failed at lint, so installations on the auto-updater never received it — v0.9.78 ships the same set plus a darker badge text on the project-card Houdini version pill so the version reads cleanly against the SideFX-orange background.

[0.9.77] – 2026-04-30

Changed

• When package install fails because a downloaded archive was published with an outdated manifest format, the launch error now reads "A package in this project was published with an outdated manifest format (missing required field 'X'). The package creator needs to republish it…" instead of dumping a raw TOML parse error. The full original error chain is still in the desktop log.

Fixed

• Dev package overrides registered for an org no longer auto-inject themselves into every project in that scope. Adding a dev override now only swaps the local path in for projects that actually depend on the package, matching what "override" implies — previously a single registered dev override would land in every project's hpm.toml, polluting the dependency list and pulling unrelated packages into the prepare flow.
• Dev package overrides linked under one scope (e.g. personal) no longer appear as linked when viewing the same package under a different scope (an organization, or a different organization). The "Dev" badge, the linked-folder readout in the package detail page, and the override applied at project prepare time are now all strictly partitioned per scope. Switching scopes also no longer briefly shows the previous scope's overrides while the new scope loads.
• Switching from one organization to another no longer briefly surfaces the previous organization's cached team projects in the projects list during the scope transition.

[0.9.76] – 2026-04-30

Added

• SideFX-typed storage entries are once again upload destinations for package releases. Configure a SideFX integration on the website (personal or org), pick it from the Upload Destination dropdown in the Release dialog, and the desktop will fetch a short-lived bearer from our API and chunk-upload your archive directly to sidefx.com's hpackage server — same flow as before the April refactor, but with the SideFX OAuth credentials held server-side instead of stored on each device. The progress bar reports just like the S3 path.
• The app's bottom status bar now reports project launch and prepare progress with the project name, the current step message, and a step counter (e.g. Snail: Starting Houdini... (4/4)). Team-project launches also report this progress now — previously the status-bar slot stayed empty for the entire wait while packages synced and Houdini started, so it wasn't obvious anything was happening between clicking Launch and Houdini's window appearing.

Fixed

• On Windows, launching a project that depends on a registry package no longer fails with Directory removal failed: Access is denied (os error 5) when another project's Houdini is already running and using the same package. HPM was redundantly reinstalling registry packages on every prepare because its "already installed" short-circuit compared scoped names (creator/slug) against bare-slug CAS entries and never matched; once a running Houdini held open file handles into the package directory, the redundant remove-then-recopy started failing. Bumps the bundled HPM to 0.9.4, which fixes the comparison and surfaces a clearer "package in use" message on the rare cases where a removal genuinely is blocked.
• Right-clicking a team project no longer logs Failed to load project scripts: Project not found, and clicking a script in that menu now actually runs it. The scripts command was looking the project up in the local personal-projects table only — team projects (which only ever live in the shared cache) always missed and the menu silently failed.
• Publishing a team project no longer fails with "method value the server doesn't accept" when an old draft on disk carries an empty or legacy env-var method. Stale drafts written by older builds are now scrubbed on load and again at the publish boundary, so any non-set/prepend/append value is coerced to set before the API sees it.
• Team project cards now show the package count from the unpublished draft when one exists, instead of the published count. Adding or removing packages in the edit form is reflected on the card immediately, fixing the "card says 2 packages but the project actually has 3" mismatch.
• Status-bar notifications now always show the most recent message. Previously a fresh error or warning was queued behind the existing one and didn't appear until the older message was dismissed or auto-cleared, so a second failed launch (for example) kept showing the first failure's text.

[0.9.75] – 2026-04-30

Added

• Package cards in the project edit form are now collapsible. Click the chevron next to a package's slug to hide its environment-variable rows — handy for projects pinning many packages where the form would otherwise scroll for ages. Cards without declared env vars don't show the chevron. Collapse state is per-form-session.

Changed

• Houdini-version pill on project cards now uses an opaque SideFX-orange (#FF6600, the official Houdini brand orange) with white text, replacing the previous tinted-orange-on-faint-orange combo that was hard to read against banner backgrounds.
• Per-package disable toggle (added in 0.9.74) is now a switch at the left of the package card instead of a power-icon button on the right. On = the package is enabled and will install/launch; off = it's skipped. The "Disabled" badge has been retired since the switch state communicates the same information more directly.

Removed

• Project pinning. The right-click Pin/Unpin action and the pinned-first sort have been retired — projects now sort purely by most-recently-used. The feature wasn't seeing real-world use, and dropping it makes the row's context menu less cluttered.

Fixed

• Team project cards no longer get stuck showing the yellow "Publish changes" badge after you edit a project and revert every change. The auto-save now compares the form against the published state and clears the draft when nothing actually differs — including disabled-package toggles that were flipped and flipped back.

[0.9.74] – 2026-04-29

Added

• Package detail page now shows a publish timestamp next to each entry in the Versions list (relative format like "3 weeks ago", with the full date on hover), making it easier to see how actively a package is maintained and whether the "latest" tag is genuinely recent.
• Project edit form's per-package card has a new power-icon toggle that disables a package without removing it. Disabled packages are skipped at install/launch (the next prepare run uninstalls them, like a regular removal), but their environment-variable overrides stay on the card and survive a re-enable — handy for short-term swaps where you don't want to lose customised values. The whole card greys out and shows a "Disabled" badge while in this state. Works on team projects too, where the toggle lives in the unpublished-changes draft alongside the rest of the form.

Changed

• Houdini-version pill on project cards is now tinted in SideFX's signature orange (replacing the previous neutral grey), so the version reads at a glance as "Houdini" rather than blending into the card chrome.

Fixed

• Removing a package from a project no longer leaves orphaned environment variables behind. Previously, any env vars the package declared in its hpm.toml (or that you'd customised on its card) would silently get promoted into the project's custom environment variables on the next save — so anything that resolved configuration via env (catalog paths, plugin search dirs, etc.) would still pick up the removed package's resources. They're now cleared as soon as the package is dropped.
• Project edit form now reliably populates the Build dropdown after picking a Houdini Version. Previously, on a cold start where the version list was fetched before the local Houdini installations had been discovered, the build could be left blank — and launching with only major.minor then failed because no installation matched the partial pin. The build dropdown now backfills as soon as discovery completes, and the form auto-picks the latest available build whenever the pinned version is incomplete.
• The "Houdini build is no longer available" recovery dialog (shown when SideFX has retired a build a project pinned) no longer crashes with Cannot read properties of undefined (reading 'filter'). The Rust-side error payload's field names were serialised as snake_case but read as camelCase by React, so the available-builds list arrived as undefined and the dialog blew up the moment it tried to render.

[0.9.73] – 2026-04-29

Internal cleanup only — re-release of 0.9.72 with a clippy-collapsible-if fix that broke the CI check step. No user-visible change from 0.9.72.

[0.9.72] – 2026-04-29

Changed

• Project banners now load from a local disk cache after the first download. Image bytes are stored under ~/.tumbletrove/banner-cache/ keyed by the banner's storage URL — every banner upload mints a fresh URL on the API side, so cache entries are immutable and never need revalidation. Previously each banner was re-fetched on every visit to the projects tab (a 4-minute in-memory cache only), causing cards to pop in one at a time. After this change, the network round-trip happens only once per banner ever, surviving app restarts.

Fixed

• Launching a team project with unpublished changes now applies those changes to the launched Houdini process. Previously, launch read only the published state of the project, so admins testing draft edits (env vars, package list, Houdini version, etc.) would see Houdini start with the pre-edit values. Drafts are still local-only — nothing is pushed to the server until you click Publish.

[0.9.71] – 2026-04-28

Changed

• Project-card action-button tooltips (Publish, Install, Launch) now render with a dark popover body and a thin colored border that matches their trigger button — yellow on the Publish tooltip, jade on Install/Launch — so the tooltip's affordance ties visually to the button it explains. The arrow tip carries the same border, and the bordered tooltips skip the open/close animation to sidestep an upstream Radix bug (#3559) where the arrow would briefly pop into place after the body's keyframe finished. The Launch button gains a tooltip too (it had none before).

Fixed

• App window no longer leaves a strip of empty body background below the status bar. The body and #root are now clamped to exactly the viewport height with overflow: hidden, which prevents Webview2's flex-chain rounding (Windows-specific) from leaking past 100vh.

[0.9.70] – 2026-04-28

Added

• Publish button on team-project cards now has a richer tooltip with a bulleted list of the fields that will be pushed (e.g. name, packages, environment), so admins can confirm what they're about to publish without opening the form.
• Every user-visible error in the app now lands in a single place — the status bar at the bottom of the window — with a one-click "Open logs" affordance and a copy of the error written to the desktop log file. Login screen, install dialog, package operations, project operations, auto-update, banner crop window — all surfaced through the same channel. No more chasing inline destructive panels in modals, settings tabs, or the projects view to find out what went wrong.

Changed

• Publishing a team project with unpublished changes is now a dedicated yellow button on the project card, rendered to the left of the Install/Launch button — replaces the previous right-click "Publish" entry. The right-click menu still offers "Discard unpublished changes". Wording across the project card and toasts now consistently says "unpublished" instead of "draft".
• Project cards no longer show the blue "update available" dot or the green "ready" checkmark. Pulling new versions of a team project that another admin has published is automatic — there's nothing for the user to act on. The yellow "syncing" spinner and the warning triangle for sync errors are still shown, since those represent in-progress or failing work.
• Project edit form now flags fields with unpublished changes by tinting the input border yellow (matching the project card convention) instead of showing a yellow asterisk next to the label. The "modified" badge that previously sat next to package env-var rows when their value differed from the package default has been removed — the yellow border conveys it more cleanly when the change is also unpublished, and the modified-vs-default distinction wasn't actionable on its own.
• Project edit form footer no longer flashes a Saving…/Saved indicator on every typing pause. Local saves are automatic and the indicator added no information; the autosave debounce is also bumped 800ms → 1500ms so brief mid-edit pauses don't fire a save.

Fixed

• Double scrollbars on the package edit form (and other tall form/list pages) — the launcher's main content area no longer competes with each view's inner scroll container, so only one vertical scrollbar is shown at a time.

[0.9.69] – 2026-04-27

Internal cleanup only.

[0.9.68] – 2026-04-27

Added

• "Default" badge on the Packages page for tumbletrove/tumbletrove, the platform-provided package every project auto-includes via the project edit form's Include default package toggle.
• Right-click → Open install folder on Packages page rows backed by a Claude Code library install — reveals the CAS install path in Finder/Explorer.
• Right-click → Open dev folder on Packages page rows with a linked dev override — reveals the dev folder in Finder/Explorer.
• Banner crop editor. Picking a project banner image now opens a separate, larger window where you can pan and zoom to the desired 5:1 crop before upload. Drag-and-drop onto the banner area still uploads the image as-is.
• Draft asterisks on the project edit form. When you're editing a team project with unpublished changes, each field whose value differs from the published version now shows a small yellow * next to its label (and on the affected env-var rows) so you can see at a glance what Publish will push.

Changed

• Project cards are tidier. The team-name and Draft text badges are gone; an unpublished team-project draft now shows up as an amber tint on the card border instead. Banners with cropped images are also more visible — the dim overlay now fades out across the card so the artwork shows through where there's no text.

Fixed

• New organizations no longer hit a dead end on the Projects tab. The "New" button stays visible (disabled with an explainer tooltip) when no team exists yet, and the empty state guides org admins to create a team first via a one-click jump to the Teams tab.
• Right-click context menus no longer paint past the window edge in the narrow desktop layout — long item labels wrap inside the available width instead of pushing the menu off-screen.
• Project edit form's package env-var rows no longer render an empty operation dropdown for env vars saved without a recorded method; the dropdown now falls back to set.

[0.9.67] – 2026-04-27

Added

• tt_* package hooks. Packages can declare reserved tt_* entries in their [scripts] table that the desktop runs at lifecycle points instead of as user-clickable buttons. tt_setup runs from the project edit form's Configure… button (returns JSON env-var overrides, persisted). tt_install runs once per package per project after the first prepare in which it appears (gated by a per-project state file) — for installing 3rd-party deps, no output read. tt_uninstall runs symmetrically when a package is removed from a project, before HPM wipes the package files. tt_prepare runs every launch and produces ephemeral env vars merged into the launch process env only (never persisted), suitable for tokens / runtime-derived paths. See the Scripts docs for the schema.

Changed

• Project edit form now shows each package's declared env vars inline on its own card, instead of in a separate section below the package list.
• Project edit form now shows package env var values exactly as the package author wrote them (e.g. $HPM_PACKAGE_ROOT/scripts) instead of the resolved absolute path.

Fixed

• Failed package and project scripts now log their stderr to the desktop log instead of failing silently.

[0.9.66] – 2026-04-27

Fixed

• Houdini install now tries the local SideFX Launcher CLI before falling back to the public builds API, so closed-beta majors (e.g. 22.x) install correctly when access is gated by per-account AUP entitlement.

[0.9.65] – 2026-04-26

Added

• Auto-update for Claude Code library plugins. App startup checks the registry; cards show an "Update vX.Y.Z" badge and the toolbar gains a bulk "Update N" affordance.

[0.9.62] – 2026-04-25

Added

• Per-env-var combine method (set / prepend / append) for project env-var overrides. Stored in the project's hpm.toml and applied with the platform path separator at launch.

Fixed

• Project edit form no longer wipes env vars when first opened.
• Project prepare recovers gracefully when a pinned Houdini build is no longer listed by the SideFX builds API.

[0.9.61] – 2026-04-25

Added

• Auto-saving project edit form (debounced 800 ms) — the Save button is gone. Personal projects sync to the API in the background after each local write.
• Local-only drafts for team projects. Edits persist locally and only ship to the server when you choose Publish from the right-click menu.
• Discard changes action on team project cards.

[0.9.60] – 2026-04-24

Fixed

• Houdini installer output is now captured even when Tauri can't pipe stdio directly on Windows (uses a cmd /c wrapper).

[0.9.59] – 2026-04-24

Fixed

• $VAR references inside scripts now expand correctly under cmd.exe on Windows.
• Banner image upload now uses the presigned PUT signature instead of a POST form.

[0.9.58] – 2026-04-23

Fixed

• Right-click menus stay inside the window edge.
• Package script execution looks up the correct CAS path for scoped (creator/slug) library packages.

[0.9.55] – 2026-04-23

Added

• Project list aggregates team projects across all organizations you belong to, not just the active scope.

Fixed

• Cleanup correctly marks a package "Unused" only when it's unused across every scope.
• Default registry is persisted on first install so subsequent install paths can find it.

[0.9.54] – 2026-04-23

Added

• Per-build platform information surfaced on package cards.
• Team Members panel closes on Esc.

Fixed

• Quieter logs during Houdini installation discovery.

[0.9.51] – 2026-04-23

Added

• Standalone Claude Code plugin library at ~/.tumbletrove/library/. Right-click any package on the Packages tab → Add to Claude Code library. Library installs go into a hidden HPM project that populates the shared CAS, plus a tumbletrove-library marketplace registered with Claude Code. The library is project-independent.
• Library-installed packages now expose their [scripts] blocks for execution from the Packages tab.
• Refreshed desktop app icons with the new TumbleTrove "TT" mark.
• Dialog open/close animations restored.

Changed

• Storage migrated to creator-scoped /v1/storage endpoints. Both personal and org creators with an S3-typed storage entry can release.
• Scripts resolve through HPM v0.8.0's platform-aware resolver, so [scripts.platform.<os>] overrides work on mixed-OS teams.

[0.9.50] – 2026-04-22

Added

• Public documentation site at docs.tumbletrove.com. Tray menu and Settings now link to it.
• Click a project card to edit; press Esc to leave subpages.

Fixed

• Team project prepare correctly resolves dev-package overrides by passing scope through.

[0.9.49] – 2026-04-21

Added

• Restart item in the system tray menu.
• Active tab and scope persist across launches.
• Window size and position persist across launches.
• New Include default package toggle on the project form. The bundled tumbletrove/tumbletrove default package is auto-injected at prepare/launch when enabled.
• SideFX Package Server uploads now report progress events.

[0.9.48] – 2026-04-21

Changed

• Renamed "context" to "project" across the UI and Tauri commands, matching the website. Existing data migrates transparently.

Added

• Houdini's splash message is set to the project name on launch.
• Run scripts directly from package cards. Project-script errors are surfaced more visibly.

Fixed

• Adding a local package or linking a dev package now auto-initialises empty folders.
• Dev packages migrate to scoped identifiers with auto-repair for legacy rows.

[0.9.42] – 2026-04-19

Added

• Long error messages on the project banner are scrollable / readable.

Fixed

• Failed Houdini installs reuse the cached installer on retry instead of redownloading multi-GB archives.
• PowerShell console no longer flashes during install.

[0.9.40 – 0.9.41] – 2026-04-17 to 2026-04-19

Added

• SideFX Houdini Launcher CLI is preferred for installs when present (/Applications/Houdini Launcher.app/..., C:\Program Files\SideFX\launcher\bin\, /opt/sidefx/launcher/bin/). Routes installs through SideFX's official tooling and unlocks closed-beta builds the public API doesn't list.
• App version + platform are logged on every startup.

Fixed

• Pass the EULA revision date to silent installs (not the build's release date).

[0.9.39] – 2026-04-17

Added

• Houdini stdio is captured to a per-project log; surfaced from the launch toast.
• Phase-by-phase logging during Houdini install with real installer errors propagated to the UI.

Fixed

• Re-launching from Start menu / Dock focuses the existing window (and forwards deep-link URLs) instead of bouncing.
• Restored UAC elevation for the Windows installer (regression).

[0.9.38] – 2026-04-16

Added

• Pre-migration database backups older than 30 days are pruned at boot.

[0.9.33] – 2026-04-15

Fixed

• License database now lives at ~/.tumbletrove/licenses.db (directory auto-created).
• Surfaced previously-silent errors across commands.

[0.9.31] – 2026-04-15

Added

• Release archive uploads stream direct to object storage via presigned URLs, instead of round-tripping through TumbleTrove's API. Bigger archives, faster uploads.

[0.9.29] – 2026-04-14

Added

• Claude Code marketplace names are scope-qualified to avoid collisions across personal/org projects.

[0.9.28] – 2026-04-14

Added

• $HPM_PACKAGE_ROOT is expanded in collected env vars.

[0.9.27] – 2026-04-14

Added

• Claude Code plugins ship alongside Houdini packages. Each project's tumbletrove-{scope} marketplace registers plugins from every installed package.

[0.9.26] – 2026-04-14

Added

• Logs are centralized at ~/.tumbletrove/logs/. Settings has an Open Logs Folder button.
• Entry / error logging across every release step.

Fixed

• Release dialog stays usable at narrow widths.
• Failed creator uploads now log the S3/API response body.

[0.9.24] – 2026-04-10

Added

• Pre-check for version conflicts before pack/upload — no more failed releases discovered after a long upload.

[0.9.23] – 2026-04-10

Fixed

• Linking a local dev override verifies that the on-disk package matches the declared identity.

[0.9.21] – 2026-04-10

Added

• Dev packages are scoped per organization.
• Block publishing a team project that depends on local-only packages.

[0.9.16] – 2026-04-09

Added

• Release dialog auto-detects missing packages and offers inline package creation.

[0.9.14] – 2026-04-09

Added

• Logs persist to disk; Open Logs Folder button in Settings.
• Error chains are preserved on the launch / sync hot paths instead of being flattened.

[0.9.13] – 2026-04-08

Added

• Env vars on the project form are grouped by package and editable inline.
• Org "release targets" appear as upload destinations in the release dialog.
• SideFX is the default upload destination.

[0.9.12] – 2026-04-08

Added

• Create new packages directly from the release dialog.

Fixed

• Houdini uninstalls batch into a single elevation prompt instead of one per install.
• Pack/release buttons show for all dev packages.

[0.9.11] – 2026-04-08

Fixed

• Dev packages match creator entries via slug from the scoped path.
• Houdini uninstall uses elevated privileges on every platform.
• Dev packages no longer render with strikethrough in the project form.
• Env vars are discovered from dev packages in the project form.

[0.9.10] – 2026-04-08

Fixed

• Scoped package paths matched correctly when discovering env vars.
• Unlinking a dev package navigates back to the package list.

[0.9.9] – 2026-04-07

Added

• Resource-deletion dialogs show which projects will be affected.

[0.9.7] – 2026-04-07

Added

• Edit dev-package metadata directly from the UI (writes back to hpm.toml).
• Migration flow for old / malformed hpm.toml files, plus a backup-and-reinit escape hatch.

Fixed

• Houdini installer runs headlessly on Windows and Linux.
• Single refresh button in the status bar (no more duplicates).

[0.9.0] – 2026-04-05

Added

• SideFX Package Server is now a first-class release target (replaces Dropbox / OneDrive).
• SideFX integration uses the website's integrations API for auth.
• Houdini-native package.json is injected into release archives.

Fixed

• Windows update installer runs silently with no visible UI.
• Cleanup can uninstall any unused Houdini version, not only those it manages.
• Long subtitle text in package cards no longer overflows.

[0.8.0] – 2026-03-31

Changed

• Scoped package paths. Packages are addressed as creator/slug everywhere. @ is reserved for version. Display name is now a free-form field separate from the slug.

[0.7.7 – 0.7.9] – 2026-03-30

Added

• Right-click context menu on project cards.
• Package detail dialog (replaces the old dev-packages section).
• Yank and Delete version controls in the package detail dialog.

Fixed

• Cleanup considers projects across all orgs when deciding what's unused.
• Deduplicated platform variants in the package version list.

[0.7.2] – 2026-03-27

Added

• Group Houdini installations by version in Settings.
• User menu re-styled as a framed button.
• Thumbnail support on package cards.
• Autostart enabled by default on fresh installs.
• Banner images auto-resized to max 800×500 before upload.

Fixed

• Removed duplicate download button when an update is available.
• Settings sidebar no longer overflows; close button placement fixed.

[0.7.0] – 2026-03-26

Added

• Cleanup tab with uninstall actions, progress feedback, and version-aware detection.
• Tauri commands for uninstalling Houdini and removing HPM packages.
• Installed tab now groups packages, exposes per-row actions, and supports navigation.
• License auto-provisioning resolves the correct package IDs in proxy mode.

[0.6.0] – 2026-03-26

Added

• License auto-provisioning at launch. Sets TUMBLETROVE_LICENSE_SERVER for the Houdini process automatically.
• Project banner is used as the Houdini splash screen.

Fixed

• Banner images load through authenticated presigned URLs.

[0.5.1] – 2026-03-26

Added

• Discover and override package env vars from the project editor.
• Platform-aware packing for native packages.

[0.5.0] – 2026-03-24

Added

• Dropbox and OneDrive as release-target providers (later replaced by SideFX in 0.9.0).
• Full-page project form with a scoped package picker.
• Check for updates button on the status bar.

Fixed

• Windows updates use passive install mode.

[0.4.2] – 2026-03-23

Fixed

• Scope isolation enforced — personal and org resources no longer cross-leak.
• Prevent duplicate hpm.toml entries; clearer registry error messages.

[0.4.0 – 0.4.1] – 2026-03-20

Added

• Package version pinning on projects.
• EntityAvatar with deterministic generated avatars.

Fixed

• Tray-icon click only opens the context menu (doesn't reopen the main window).

[0.3.7] – 2026-03-20

Added

• Org-created packages appear on the Packages tab.
• Run package scripts directly from the project's launch dropdown.

[0.3.5 – 0.3.6] – 2026-03-18 to 2026-03-19

Added

• Drag-and-drop banner image on the project form.
• Minimum window width reduced to 420 px.

Changed

• Minimize-to-tray enabled by default on every platform.

[0.3.2] – 2026-03-17

Added

• Always show the build selector with explicit build numbers.
• Precise Houdini version selection (major.minor.build) per project.

Changed

• Renamed "HoudiniHub" → TumbleTrove in the title bar; placeholder logo removed.

[0.3.0] – 2026-03-17

Added

• Banner image support on project cards.
• Global dev packages UI — replaces per-project local packages.

[0.2.1] – 2026-03-16

Added

• Custom tray icon and an enhanced tray menu listing recent projects.

Fixed

• Personal-scope packages use the creator API (showed up correctly on the Packages tab).

[0.2.0] – 2026-03-12

Added

• Local dev packages, package scaffolding, and the release pipeline.

[0.1.2] – 2026-03-11

Changed

• Credential storage moved to disk at ~/.tumbletrove/credentials.json (0o600 on Unix), replacing the OS keyring. Platform-keychain integration is on the roadmap.

Added

• "Recheck for updates" affordance.

[0.1.1] – 2026-03-11

First publicly-released build. Multi-platform CI, code-signing, and the Tauri auto-updater landed here.