skydive-cli 0.1.0-beta.96 → 0.2.0-beta.421

package/CHANGELOG.md

@@ -0,0 +1,68 @@
+# Changelog
+
+All notable changes to the Skydive CLI are documented here.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [0.2.0] - 2026-07-29
+
+### Added
+
+**Sandbox & machine access**
+
+- Standalone `skydive sandbox` command for direct access to an agent's sandbox.
+- `/sandbox` in the chat TUI — live PTY session and one-shot command execution.
+- Headless machine sharing via `skydive portal`, with self-registering portal grants.
+- `shareMachineDefault` config key for always-on portal sharing.
+
+**Chat TUI**
+
+- File pane (`ctrl+g`) with Changes and Files tabs: a shared file tree plus source viewer and a workspace browser, mouse-resizable and responsive to terminal size.
+- Agent todo list rendered in the chat TUI, above the composer, mirroring the web chat's todo card.
+- Fuzzy finder in the conversation and agent pickers.
+- Slash-command autocomplete menu.
+- Paste or drag-and-drop any file into the composer; paste clipboard images with Cmd+V.
+- Run local shell commands with `!` in the composer.
+- Conversation recaps, streamed live title updates, and per-agent attribution on assistant turns.
+- Working timer rolls up into minutes and hours.
+- Conversation picker paginates past 50 conversations and shows only your own conversations.
+- Esc leaves a live run; typing `exit` quits the chat.
+- Cursor Dark theme.
+- Picker rows no longer overlap when a conversation title contains a newline, tab, or control character.
+
+**Headless & scripting**
+
+- Resume a conversation by id.
+- `conversations list` and `conversations show` for transcript reads.
+- `messages get`, with run recovery keyed on message id.
+- Connect cards surface in headless `-p` mode so a driving agent never gets stuck.
+
+**Authentication**
+
+- `skydive auth login` via the browser now auto-mints an API key, so one login yields both a chat session and a usable management credential. Management commands announce the key's pinned workspace when it drives them, so a workspace mismatch is visible at use time.
+- Workspace picker on the device authorization page.
+- Account and workspace identity shown in `auth status`.
+
+**Platform**
+
+- Standalone binary builds compiling the CLI into a per-target executable.
+- Interactive workspace switcher; management commands follow the active workspace.
+- Terminal host integrations and agent notifications.
+
+### Fixed
+
+- Transcript errors collapse to one line, click to expand (REST and portal errors keep their full body).
+- Dragged/pasted image file paths attach the file instead of inserting path text, including macOS paths with literal parentheses.
+- Bare URLs in chat markdown are hyperlinked so they survive text wrap.
+- Composer draft is preserved across TUI overlays.
+- Relative connect links resolve before opening the browser.
+- Numbered markdown headings render colored in the TUI.
+- Chat transcript pages by 75% of a screen; picker rows stay on one line.
+- Run starts push to the TUI over the conversation stream.
+- Security: remediated high-severity dependency findings and cleared tar/shell-quote CVEs.
+
+## [0.1.0] - 2026-07-21
+
+Initial public release: `skydive chat` TUI, agent and conversation management,
+device authorization, and headless `-p` mode.

package/README.md

@@ -8,9 +8,48 @@ npx skydive-cli --help
 
 ## Authentication
 
-The CLI has two credentials, stored together in a single `config.json`. The
-location is platform-conventional (resolved via `env-paths`), so it is **not**
-`~/.config/skydive/` everywhere:
+Sign in once via the browser — the same shape as `doppler login`: the CLI
+opens the approval page, shows a short code, waits for you to approve, and
+then automatically mints an API key for this machine:
+
+```sh
+skydive auth login
+```
+
+That single flow yields both credentials the CLI uses, stored together in a
+single `config.json`:
+
+- an **API key** (`sky_live_…`) named after this machine and the workspace it
+  was minted in (`CLI (host) — Acme`) — the durable credential for the
+  management commands (`agents`, `keys`, `secrets`). Logging in again from the
+  same machine replaces it rather than accumulating rows, and
+  `skydive auth logout` revokes it, so signing out doesn't leave a live key
+  behind. The workspace is in the name because the key is pinned to it: unlike
+  the session, a key never follows `workspace switch` — and whenever the key
+  (not the session) is the credential actually driving a management command,
+  the CLI says so on stderr, naming the pinned workspace, so commands never
+  silently act in a workspace you switched away from.
+- a **user session** for `skydive chat`. Chat is user-level and multi-agent,
+  so it authenticates as you — and unlike the API key (which is pinned to the
+  workspace that minted it), the session follows `skydive workspace switch`.
+  The management commands prefer the session while it's valid and fall back
+  to the API key.
+
+The flow doesn't require a TTY: in a non-interactive shell (an agent harness,
+SSH without a display) `auth login` still prints the verification URL + code
+and waits — open the link in any browser to approve. For unattended CI, skip
+the wait entirely and pass an existing key (mint one at
+`skydive.com/settings/account`):
+
+```sh
+skydive auth login --api-key sky_live_…   # or set SKYDIVE_API_KEY
+```
+
+`skydive auth status` shows both credentials; `skydive auth logout` revokes
+the auto-minted key and clears them.
+
+The config location is platform-conventional (resolved via `env-paths`), so
+it is **not** `~/.config/skydive/` everywhere:
 
 | Platform | Path                                                             |
 | -------- | ---------------------------------------------------------------- |
@@ -21,29 +60,6 @@ location is platform-conventional (resolved via `env-paths`), so it is **not**
 `skydive auth status` prints the real resolved path (`Config: …`) — trust that
 over this table if they ever disagree.
 
-- **API key** (`sky_live_…`). Mint one at `skydive.com/account`, then:
-
-  ```sh
-  skydive auth login            # paste the key
-  ```
-
-- **User session** for `skydive chat`. Chat is user-level and multi-agent,
-  so it signs you in via the browser (device flow) rather than a per-agent
-  API key. `skydive chat` does this automatically on first run; you can also
-  do it up front:
-
-  ```sh
-  skydive auth login --web      # opens the browser, prompts for approval
-  ```
-
-Either credential authenticates the management commands (`agents`, `keys`,
-`secrets`): the CLI prefers the API key and falls back to the `--web` chat
-session, so a `--web` login alone is enough to run them — you do **not** need a
-separate API key. The API key is only required when you have no chat session
-(e.g. CI). `skydive chat` requires the chat session specifically.
-
-`skydive auth status` shows both; `skydive auth logout` clears them.
-
 ## Commands
 
 ```sh
@@ -61,10 +77,62 @@ skydive secrets rm <KEY> --agent-id <id>
 
 skydive chat                    # interactive chat TUI (Node; fetches Bun on first run)
 skydive chat -p "<prompt>"       # one-shot, non-interactive (runs under Node)
+
+skydive import                  # agent imports your Claude Code / Cursor / OpenCode setup
+
+skydive portal open             # open the portal to this machine, headless
+skydive portal grant --agent <id|name>
+skydive portal revoke --agent <id|name>
+skydive portal status
 ```
 
 Global flags: `--json`, `--quiet`, `--api-url <url>`.
 
+## `skydive import`
+
+Migrating from Claude Code, Cursor, or OpenCode? `skydive import` opens a
+chat with your agent, shares this machine with it, and asks it to import
+your setup — instruction files, skills, slash commands, memory, MCP
+servers. The agent inventories what you have, shows you a plan (including
+what it will NOT bring: credentials never come along; hooks and
+settings have no equivalent here), and only commits to its repo after you
+say yes. Run it from a project directory so project-level config is found
+too.
+
+```sh
+skydive import                 # picks your only agent, or opens the picker
+skydive import --agent kit     # import into a specific agent
+```
+
+The heavy lifting is the agent's `import-config` skill, so you can also just
+ask in any machine-shared chat: "import my Claude Code setup".
+
+Non-interactive (scripts, or driving it from another coding agent):
+`skydive import -p --agent kit` sends the request as a one-shot and prints
+the agent's plan — the agent still waits for approval, so continue with
+`skydive chat -p "go ahead" --agent <id> --resume <conversation> --share-machine`
+to apply it. Runs under Node, no TTY needed.
+
+## Workspaces
+
+Every `skydive` command acts inside one **workspace** — the org/team boundary
+that owns your agents, conversations, and secrets. If your account belongs to
+several workspaces (say, your company org and a personal one), the same agent
+name can exist in both, so which workspace is active determines what every
+command sees.
+
+- `skydive workspace list` — workspaces on your account, with the active one
+  marked.
+- `skydive workspace switch [workspace]` — change the active workspace. All
+  commands — `agents`, `secrets`, `keys`, `chat`, `conversations` — follow it.
+- `skydive auth status` — shows who you're logged in as and which workspace is
+  active.
+- In the chat TUI, `ctrl+w` switches workspace from the agent picker.
+
+The active workspace is stored in the CLI config file and persists across
+invocations. If a command can't find an agent you know exists, check
+`skydive auth status` first — you're probably in the wrong workspace.
+
 ## `skydive secrets`
 
 Manage the environment secrets injected into an agent's sandbox. All
@@ -139,21 +207,22 @@ skydive chat -p "status?" --agent grace --json               # structured envelo
 - `--conversation <id>` continues an existing thread; omitted, it starts a new
   one. The conversation id is included in `--json` output for chaining.
 - `-p` needs a user session just like `chat`, but never opens the interactive
-  browser login — sign in first with `skydive auth login --web` or set
+  browser login — sign in first with `skydive auth login` or set
   `SKYDIVE_SESSION_TOKEN`.
 - `--json` prints `{ agentId, agentName, conversationId, isNewConversation,
-runId, text }` instead of streaming the raw text.
+messageId, text }` instead of streaming the raw text.
 - **Recovering a dropped run.** A long run's stream can be cut off at the edge
-  (a gateway 502/504) after the run was created. The run keeps going
-  server-side, so a blind retry would re-execute the agent. Instead, note the
-  `runId` (always in `--json` output) and fetch the result once it's done:
+  (a gateway 502/504) after the message was accepted. The agent keeps working
+  server-side, so a blind retry would re-execute it. Instead, note the
+  `messageId` (always in `--json` output) and fetch the result once it's done:
 
   ```sh
-  skydive runs get <runId>            # prints the reply; --json for the envelope
+  skydive messages get <messageId>    # prints the reply; --json for the envelope
   ```
 
-  `runs get` re-attaches to the run and replays its full reply whether it's
-  still streaming or already finished.
+  `messages get` re-attaches to the exchange behind that message id and replays
+  the full reply whether it's still streaming or already finished. Message ids
+  are the handle this API works in; run ids stay server-side.
 
 It defaults to the production API (`https://api.skydive.com`). For local
 dev, point it at your stack:
@@ -203,7 +272,10 @@ This is off by default (default-deny) and you opt in explicitly:
 
 - `skydive chat --share-machine` enables it at launch, or
 - `ctrl+t` toggles it from the chat screen (the status bar shows `local access`
-  when on, `revoke access` when off).
+  when on, `revoke access` when off), or
+- set `"shareMachineDefault": true` in the CLI config file to share on every
+  launch (see [Configuration](#configuration); `--no-share-machine` overrides
+  once).
 
 What to know before enabling it:
 
@@ -217,12 +289,70 @@ What to know before enabling it:
   outside the launch directory. Launch from a scoped directory, but treat the
   grant as "this agent can act as me on this machine," not "this agent can only
   see this folder."
-- **Teardown is automatic.** Access is revoked when the TUI unmounts, so
-  quitting the chat drops the grant and reaps any processes the agent spawned.
-- **Interactive only.** Machine sharing is **not** available in `-p`
-  (non-interactive) mode \u2014 `--share-machine` has no effect there and the
-  print path carries no portal code. You can have scripted (`-p`) or local
-  access, not both, in a single invocation.
+- **Teardown drops reachability, not the grant.** Quitting the chat closes the
+  portal connection (the machine becomes unreachable) and reaps any processes
+  the agent spawned, but the per-agent grant itself **persists** until you
+  revoke it (`skydive portal revoke` or the web app). The next time this
+  machine shares, previously granted agents can run commands immediately, with
+  no new prompt.
+- **The TUI is not required.** With `-p`, `--share-machine` shares this machine
+  for the duration of that one run: the portal connects before the prompt is
+  sent, the target agent is granted access (the flag is the consent — there is
+  no prompt to approve), and the connection is torn down when the run ends.
+  For access that outlives a single run, use `skydive portal open` (below).
+  When sharing comes from `shareMachineDefault` rather than the explicit
+  flag, no new grant is minted — the machine connects and already-granted
+  agents can run, but an ungranted agent still needs `skydive portal grant`
+  (or an approved request).
+
+### Headless machine access (`skydive portal`)
+
+`skydive portal` manages machine sharing without the TUI, for scripts, CI-ish
+environments, and driving agents from other tools:
+
+```sh
+skydive portal open                    # connect and stay in the foreground (ctrl+c to close)
+skydive portal open --agent grace      # …and grant that agent on first connect
+skydive portal open --cwd ~/some/repo  # working directory for the agent's commands (a starting point, not a boundary — see above)
+skydive portal grant --agent grace     # allow an agent (registers this machine if needed)
+skydive portal revoke --agent grace     # remove an agent's access
+skydive portal status                   # machines, connection state, granted agents
+```
+
+Semantics match the TUI exactly \u2014 same default-deny grants, same audit log,
+same server-side kill switch. `open` keeps the machine reachable only while
+the process runs (park it in tmux for long-lived access); `grant`/`revoke`
+edit the persistent per-agent access.
+
+Two unattended patterns:
+
+- **One-shot:** `skydive chat -p "<prompt>" --agent <name> --share-machine` \u2014
+  shares, grants the target agent, runs the prompt, tears down.
+- **Daemon:** one `skydive portal open` process, plus plain
+  `skydive chat -p "<prompt>" --agent <name>` one-shots from another shell \u2014
+  cheaper when firing many prompts, since each one skips the connect/grant.
+
+## Configuration
+
+Persistent state lives in a per-user JSON file managed by
+[`conf`](https://github.com/sindresorhus/conf):
+`~/Library/Preferences/skydive/config.json` on macOS,
+`~/.config/skydive/config.json` on Linux (profile name follows
+`SKYDIVE_CONFIG_NAME`). Most keys are written by flows — `auth login`, the
+device-login flow, the in-TUI theme picker — but the file is plain JSON and
+read fresh on every invocation, so preference keys can be set by editing it
+directly. There is deliberately no `skydive config` command.
+
+Hand-editable keys:
+
+| Key                   | Type    | Effect                                                                                                                                                                                                                          |
+| --------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `shareMachineDefault` | boolean | When `true`, `skydive chat` (TUI and `-p`) shares this machine over the portal on launch, as if `--share-machine` were passed. An explicit `--share-machine`/`--no-share-machine` overrides it per invocation. Default `false`. |
+| `updateCheck`         | boolean | When `false`, disables the daily background update check and its "Update available" notice. The persistent equivalent of setting `SKYDIVE_NO_UPDATE_CHECK` (or `NO_UPDATE_NOTIFIER`) in the environment. Default `true`.        |
+
+The remaining keys (`apiKey`, `apiUrl`, `sessionToken`, `appUrl`, `themeDark`,
+`themeLight`, …) are credentials or flow-managed state — leave them to the
+CLI.
 
 ## Environment variables
 
@@ -257,3 +387,19 @@ them as a sticky screenshot comment on CLI PRs.
 
 The pattern (stub `fetch`, seed the store, drive keys, assert on
 `captureCharFrame()`) is in `src/chat/tui/screens/agent-picker.tui.test.tsx`.
+
+## Building a standalone binary
+
+`yarn build:binary` compiles the CLI into a single self-contained executable
+(`dist/binaries/skydive-<target>`) with `bun build --compile` — no Node or
+Bun needed on the machine that runs it, including for the OpenTUI chat
+(`ensureBunAndReexec` no-ops because the binary _is_ Bun). Needs Bun ≥ 1.3.14
+to build; pass `--target` for one of `bun-darwin-arm64`, `bun-darwin-x64`,
+`bun-linux-x64`, `bun-linux-arm64` (defaults to the host, and the target's
+`@opentui/core-*` optional dependency must be installed).
+
+The script encodes three non-obvious constraints (older Bun emits unsignable
+Mach-Os, OpenTUI's tree-sitter worker needs explicit embedding, and
+`NODE_ENV=production` silently breaks highlight repaints) — see the header
+comment in `scripts/build-binary.ts` before changing any of the flags it
+passes.

package/dist/js/api-CDTKq_5Q.mjs

@@ -0,0 +1,145 @@
+#!/usr/bin/env node
+import { t as HttpError } from "./rest-CamHVOce.mjs";
+import os from "node:os";
+import { z } from "zod";
+
+//#region src/chat/portal/machine.ts
+/**
+* Identity this machine registers under when the CLI shares it via the portal.
+*
+* The `-cli` suffix / `(CLI)` label keep a CLI-shared machine a DISTINCT portal
+* device from the same host's Skydive Desktop app. `portal_device` is unique on
+* (org, user, machineName), and directives route to whichever socket holds the
+* device — if the CLI and desktop registered the same name they'd share a
+* device row and both execute every directive. Distinct names also make the
+* grant UI unambiguous about which surface is being authorized.
+*/
+function machineIdentity() {
+	const host = (os.hostname() || "machine").trim().replace(/\.local$/i, "") || "machine";
+	return {
+		machineName: `${host}-cli`,
+		friendlyName: `${host} (CLI)`
+	};
+}
+const INHERITED_ENV = [
+	"HOME",
+	"USER",
+	"LOGNAME",
+	"SHELL",
+	"LANG",
+	"LC_ALL",
+	"TMPDIR",
+	"TERM",
+	"PATH"
+];
+function buildEnv(extra) {
+	const env = {};
+	for (const key of INHERITED_ENV) {
+		const value = process.env[key];
+		if (value !== void 0) env[key] = value;
+	}
+	if (extra) for (const [key, value] of Object.entries(extra)) env[key] = value;
+	return env;
+}
+/**
+* Build the desktop-portal WebSocket URL from the chat origin. Mirrors the Rust
+* desktop client: http→ws, https→wss, scheme-less defaults to wss, and the
+* machine/label ride as query pairs (percent-encoded by URL).
+*/
+function portalWsUrl(appUrl, machine, label) {
+	const base = appUrl.replace(/\/+$/, "");
+	let wsBase;
+	if (base.startsWith("https://")) wsBase = `wss://${base.slice(8)}`;
+	else if (base.startsWith("http://")) wsBase = `ws://${base.slice(7)}`;
+	else wsBase = `wss://${base}`;
+	const url = new URL(`${wsBase}/api/v1/portal/desktop`);
+	url.searchParams.set("machine", machine);
+	url.searchParams.set("label", label);
+	return url.toString();
+}
+
+//#endregion
+//#region src/chat/portal/api.ts
+/**
+* The portal's session-authed REST surface, shared by `PortalClient` (the
+* TUI/`portal open` connection) and the `skydive portal` management
+* commands, so the endpoint contracts and response schemas live in exactly
+* one place.
+*/
+const deviceSchema = z.object({
+	id: z.string(),
+	machineName: z.string(),
+	friendlyName: z.string(),
+	connected: z.boolean(),
+	lastSeen: z.string().nullable(),
+	grantedAgentIds: z.array(z.string())
+});
+const devicesResponseSchema = z.object({
+	devices: z.array(deviceSchema),
+	agents: z.array(z.object({
+		id: z.string(),
+		name: z.string()
+	}))
+});
+const deviceTokenSchema = z.object({ token: z.string().min(1) });
+async function portalFetch(auth, path, init) {
+	const res = await fetch(`${auth.appUrl}${path}`, {
+		method: init.method,
+		headers: {
+			authorization: `Bearer ${auth.sessionToken}`,
+			accept: "application/json",
+			...init.body ? { "content-type": "application/json" } : {}
+		},
+		...init.body ? { body: init.body } : {}
+	});
+	if (!res.ok) {
+		const body = await res.text().catch(() => "");
+		throw new HttpError(res.status, body);
+	}
+	return res.json();
+}
+async function fetchPortalDevices(auth) {
+	const json = await portalFetch(auth, "/api/v1/portal/devices", { method: "GET" });
+	return devicesResponseSchema.parse(json);
+}
+const registerResponseSchema = z.object({ device: z.object({ id: z.string() }) });
+/**
+* Register this machine's device row without connecting. Connecting registers
+* as a side effect; this covers granting an agent on a machine that has never
+* shared yet (the grant references the device row).
+*/
+async function registerPortalDevice(auth, { machineName, friendlyName }) {
+	const json = await portalFetch(auth, "/api/v1/portal/devices", {
+		method: "POST",
+		body: JSON.stringify({
+			machineName,
+			friendlyName
+		})
+	});
+	return registerResponseSchema.parse(json).device;
+}
+/** Short-lived token the machine presents when dialing the portal WebSocket. */
+async function mintPortalDeviceToken(auth) {
+	const json = await portalFetch(auth, "/api/v1/portal/device-token", { method: "POST" });
+	return deviceTokenSchema.parse(json).token;
+}
+async function grantPortalAccess(auth, { deviceId, agentId }) {
+	await portalFetch(auth, `/api/v1/portal/devices/${encodeURIComponent(deviceId)}/grants`, {
+		method: "POST",
+		body: JSON.stringify({ agentId })
+	});
+}
+async function revokePortalAccess(auth, { deviceId, agentId }) {
+	await portalFetch(auth, `/api/v1/portal/devices/${encodeURIComponent(deviceId)}/grants/${encodeURIComponent(agentId)}`, { method: "DELETE" });
+}
+/**
+* The device row for a given machine identity. Matching is by `machineName`
+* equality — the stable per-surface handle (`<host>-cli` vs the desktop's
+* `<host>`), not the display label.
+*/
+function findThisDevice(devices, machineName) {
+	return devices.find((device) => device.machineName === machineName) ?? null;
+}
+
+//#endregion
+export { registerPortalDevice as a, machineIdentity as c, mintPortalDeviceToken as i, portalWsUrl as l, findThisDevice as n, revokePortalAccess as o, grantPortalAccess as r, buildEnv as s, fetchPortalDevices as t };