@puddle-code/cli 0.0.33 → 0.0.34
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +4 -6
- package/README.md +18 -10
- package/dist/index.js +1024 -454
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -7,12 +7,10 @@ Past releases: see docs/changelogs/.
|
|
|
7
7
|
|
|
8
8
|
# Changelog
|
|
9
9
|
|
|
10
|
-
## [0.0.
|
|
10
|
+
## [0.0.34] — 2026-08-07
|
|
11
11
|
|
|
12
12
|
### Added
|
|
13
13
|
|
|
14
|
-
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
- Auto-theming agents (e.g. Claude Code with `theme: auto`) no longer come up dark under a light puddle theme: they sample the terminal background at spawn, usually before any viewer has attached, so the browser-side answer to their OSC 10/11 colour query arrived for nobody. The daemon now answers those queries itself, from the colours the client reports over the WS on connect and on every theme switch (protocol 14.1, additive — against an older daemon the viewer-side answering remains). A running agent that already sampled keeps its choice until its next start/resume.
|
|
14
|
+
- `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`).
|
|
15
|
+
- `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.
|
|
16
|
+
- `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
CHANGED
|
@@ -54,11 +54,21 @@ Daemon-only installs (no CLI) use the `install.sh` attached to each release —
|
|
|
54
54
|
curl -fsSL https://github.com/PerceptronV/puddle-code/releases/latest/download/install.sh | sh
|
|
55
55
|
```
|
|
56
56
|
|
|
57
|
+
**Managing components:**
|
|
58
|
+
|
|
59
|
+
The CLI installs, upgrades, and removes all three components — daemon, desktop app, and itself — with optional versions and SSH targets:
|
|
60
|
+
|
|
61
|
+
```sh
|
|
62
|
+
puddle upgrade # everything installed → the newest release
|
|
63
|
+
puddle install daemon@v0.0.32 user@host # pin a host's daemon to a version
|
|
64
|
+
puddle remove daemon # uninstall; your data stays unless you --purge
|
|
65
|
+
```
|
|
66
|
+
|
|
57
67
|
**Desktop app (optional):**
|
|
58
68
|
|
|
59
69
|
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.
|
|
60
70
|
|
|
61
|
-
|
|
71
|
+
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.
|
|
62
72
|
|
|
63
73
|
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:
|
|
64
74
|
|
|
@@ -92,7 +102,7 @@ Building from source avoids the dance entirely (locally built apps are never qua
|
|
|
92
102
|
|
|
93
103
|
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.
|
|
94
104
|
|
|
95
|
-
Everything lives under `~/.puddle` on the host, installed without sudo
|
|
105
|
+
Everything lives under `~/.puddle` on the host, installed without sudo — and `puddle remove daemon` takes it apart again.
|
|
96
106
|
|
|
97
107
|
## Development & teardown
|
|
98
108
|
|
|
@@ -115,19 +125,17 @@ systemctl --user disable --now puddled # Linux (systemd user unit)
|
|
|
115
125
|
kill "$(cat ~/.puddle/puddled.pid)" # nohup fallback (no supervisor)
|
|
116
126
|
```
|
|
117
127
|
|
|
118
|
-
**Restore the production daemon.** When you're done testing,
|
|
119
|
-
|
|
120
|
-
**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:
|
|
128
|
+
**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.)
|
|
121
129
|
|
|
122
|
-
|
|
130
|
+
**Uninstall.** Removing the CLI alone leaves the daemon installed and running — a full teardown is:
|
|
123
131
|
|
|
124
132
|
```sh
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
rm ~/.config/systemd/user/puddled.service && systemctl --user daemon-reload # Linux
|
|
128
|
-
npm uninstall -g @puddle-code/cli
|
|
133
|
+
puddle remove daemon --purge # stops the daemon, unregisters its service, deletes ~/.puddle
|
|
134
|
+
puddle remove cli # npm uninstall -g, once the daemons you care about are gone
|
|
129
135
|
```
|
|
130
136
|
|
|
137
|
+
> ⚠️ `~/.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.
|
|
138
|
+
|
|
131
139
|
## Licence
|
|
132
140
|
|
|
133
141
|
Puddle is licensed under the [MIT License](LICENSE). Copyright (c) 2026 Yiding Song.
|