@puddle-code/cli 0.0.32 → 0.0.34

package/CHANGELOG.md

@@ -7,22 +7,10 @@ Past releases: see docs/changelogs/.
 
 # Changelog
 
-## [0.0.32] — 2026-08-06
-
-### Changed
-
-- Protocol 14.0: a forced-upgrade major with no schema change beyond 13.1's additive login `hint` (the 6.0/8.0/…/13.0 pattern). The fixed login flows are daemon-side behaviour a client cannot detect or route around — a 13.x daemon still runs the subcommand logins (codex's empty panel included) and never verifies a login's clean exit — so every connected daemon auto-upgrades at its next handshake.
+## [0.0.34] — 2026-08-07
 
 ### Added
 
-- Remote cockpits now carry the client's `localhost:1455` to the host over the SSH master connection (best-effort, skipped with a warning when the local port is busy), so codex's ChatGPT sign-in completes from a remote cockpit: its OAuth flow redirects the client browser to a registered `http://localhost:1455/…` callback that no proxy rewrite can reach — the fixed forward is codex's own documented headless-SSH recipe, now automatic.
-
-### Changed
-
-- Account renaming is discoverable: a pencil beside the account name in Settings → Accounts starts the edit (the name was already an inline-editable field, but nothing said so until it was hovered).
-- The account login dialogue is near-fullscreen: the login is the agent's first-run TUI now, so it gets a real terminal's canvas rather than the 28rem box sized for the old subcommand flows.
-
-### Fixed
-
-- Codex login no longer shows an empty panel on remote hosts: `codex login` opens a browser and a localhost OAuth callback on the DAEMON host while rendering nothing in the PTY. The login dialogue now runs the bare `codex` TUI — its own first-run sign-in screen (ChatGPT or API key) renders in the terminal, matching the Claude Code login flow — with the dialogue hint explaining how to exit once signed in. Gemini CLI's (already TUI-based) login gains the same hint; OpenCode keeps `auth login`, which renders in the PTY and exits cleanly by itself.
-- Switching (or creating) a profile now lands on that profile's dashboard. The picker replaced the router without touching the address, so the previous profile's project URL was still current when the router came back — and a project route binds the workspace to the project's OWNING profile, so a brand-new profile appeared to have inherited the old profile's projects, sessions, and layout wholesale.
+- `puddle install <daemon|desktop>[@version] [user@host]` — ensure a component is present: a no-op (that says so) when it already is and no version is named; an exact version otherwise, downgrades included. On Linux, `install desktop` asks where the AppImage should live (default `~/puddle`; the checksum-verified file lands as `Puddle.AppImage` so launchers and the in-app updater keep a fixed path) and opens the folder in the file manager. Pinning the daemon to a version other than the CLI's own prints a warning that the next `puddle launch` would force-upgrade it across a protocol major (pin the CLI too, or launch `--no-upgrade`).
+- `puddle upgrade` grows components and versions: `[cli|daemon|desktop][@version] [user@host]` moves one component to the newest release (resolved from GitHub, falling back to the CLI's version train offline) or the named one, installing it when missing; **bare `puddle upgrade` now upgrades everything installed on the target** (previously it meant the CLI alone), the CLI strictly last since npm replaces the running code; `upgrade cli` is a valid spelling again.
+- `puddle remove <cli|daemon|desktop> [user@host]` — confirmed removal, defaulting to no (`--yes` for scripts). Removing the daemon lists its version, the running sessions it interrupts, and its profiles first; it stops and unregisters the supervisor (systemd/launchd/nohup) and keeps `~/.puddle`'s data — profiles, session history, worktrees, credentials — unless separately confirmed (`--purge`), and before purging it sweeps worktrees for uncommitted or unpushed work and asks again when it finds any. cli removal requires a real npm global install; desktop removal deletes the closed macOS bundle and its staged-update cache.

package/README.md

@@ -54,11 +54,21 @@ Daemon-only installs (no CLI) use the `install.sh` attached to each release —
 curl -fsSL https://github.com/PerceptronV/puddle-code/releases/latest/download/install.sh | sh
 ```
 
+**Managing components:**
+
+The CLI installs, upgrades, and removes all three components — daemon, desktop app, and itself — with optional versions and SSH targets:
+
+```sh
+puddle upgrade                            # everything installed → the newest release
+puddle install daemon@v0.0.32 user@host   # pin a host's daemon to a version
+puddle remove daemon                      # uninstall; your data stays unless you --purge
+```
+
 **Desktop app (optional):**
 
 The same cockpit also ships as a standalone desktop app — identical UI and engine, plus a File → "Connect to SSH Host…" menu for remote hosts. Grab the dmg (macOS arm64) or AppImage (Linux x64) from the Releases page.
 
-On macOS, an installed Puddle CLI can install or update the desktop app directly: quit Puddle, then run `puddle upgrade desktop`. A fresh install goes to `/Applications` when writable, otherwise `~/Applications`.
+An installed Puddle CLI manages the desktop app directly: quit Puddle, then `puddle install desktop`, `puddle upgrade desktop`, or `puddle remove desktop`. On macOS a fresh install goes to `/Applications` when writable, otherwise `~/Applications`; on Linux `install desktop` asks where to put the AppImage (default `~/puddle`) and opens the folder — later updates happen from inside the app.
 
 The macOS downloads are **not code-signed** (an open-source project without Apple Developer Program fees), so Gatekeeper will refuse the first launch. Either allow it once — open the app, let macOS block it, then System Settings → Privacy & Security → **Open Anyway** — or clear the download quarantine in a terminal:
 
@@ -92,7 +102,7 @@ Building from source avoids the dance entirely (locally built apps are never qua
 
 The CLI serves the UI at a stable local origin and reverse-proxies the API to the daemon, directly in local mode, through the tunnel in SSH mode. The daemon is headless and host-agnostic on `127.0.0.1:7434`. UI updates ship with the CLI (`npm update -g @puddle-code/cli` refreshes the cockpit for every host); the daemon only has to update when the versioned protocol breaks, and the CLI does that automatically. A mandatory bearer token plus Host/Origin validation guard the localhost API against malicious web pages.
 
-Everything lives under `~/.puddle` on the host, installed without sudo. Uninstalling is stopping the service and deleting that directory.
+Everything lives under `~/.puddle` on the host, installed without sudo — and `puddle remove daemon` takes it apart again.
 
 ## Development & teardown
 
@@ -115,19 +125,17 @@ systemctl --user disable --now puddled              # Linux (systemd user unit)
 kill "$(cat ~/.puddle/puddled.pid)"                 # nohup fallback (no supervisor)
 ```
 
-**Restore the production daemon.** When you're done testing, put the release build back over your dev one: stop the daemon (above), clear the installed binaries with `rm -rf ~/.puddle/bin` (your `~/.puddle` state — profiles, sessions, worktrees — is untouched), then run the production `puddle launch`, which refetches the daemon from GitHub Releases. (Clearing `bin` is what forces the refetch: the installer skips a version whose files are already present, so a dev build sharing the release's version number would otherwise stay put.)
-
-**Uninstall.** Removing the CLI alone leaves the daemon installed and running — a full teardown stops the daemon, then removes its state, its service file, and the production CLI:
+**Restore the production daemon.** When you're done testing, `puddle remove daemon` (answer no to the purge question — your profiles, sessions, and worktrees stay), then run the production `puddle launch`, which refetches the daemon from GitHub Releases. (Removal is what forces the refetch: the installer skips a version whose files are already present, so a dev build sharing the release's version number would otherwise stay put.)
 
-> ⚠️ `~/.puddle` **is** your local state — the SQLite database with every profile, account, and session (plus conversation history), the daemon's worktree tracking, and the auth token. Deleting it is irreversible and wipes all of it. Uninstall only when you mean to start clean.
+**Uninstall.** Removing the CLI alone leaves the daemon installed and running — a full teardown is:
 
 ```sh
-rm -rf ~/.puddle
-rm ~/Library/LaunchAgents/dev.puddle.puddled.plist                            # macOS
-rm ~/.config/systemd/user/puddled.service && systemctl --user daemon-reload   # Linux
-npm uninstall -g @puddle-code/cli
+puddle remove daemon --purge   # stops the daemon, unregisters its service, deletes ~/.puddle
+puddle remove cli              # npm uninstall -g, once the daemons you care about are gone
 ```
 
+> ⚠️ `~/.puddle` **is** your local state — the SQLite database with every profile, account, and session (plus conversation history), the daemon's worktree tracking, and the auth token. `--purge` deletes it irreversibly (the command lists dirty or unpushed worktrees and asks first); without it, `puddle remove daemon` keeps the data for a later reinstall.
+
 ## Licence
 
 Puddle is licensed under the [MIT License](LICENSE). Copyright (c) 2026 Yiding Song.