@shardflux/cli 0.20.0 → 0.22.0

package/CHANGELOG.md

@@ -1,6 +1,219 @@
 # Changelog
 
-## 0.20.0 (not yet published)
+## 0.22.0 (2026-10-13)
+
+- **Starts send only what changed.** A new conversation's project travels as Git packs into a project cache its VMs
+  share: a start sends only what the cache lacks (a second chat on the same state sends nothing; a one-file edit sends
+  its delta), in 8 MiB binary parts, four at a time, resumable after an interruption. Dirty and untracked files go
+  once, not as a copy and again in the snapshot.
+- **Large media follow the first prompt.** Untracked images, audio and video of 256 KiB and more stay out of the twin
+  snapshot and land in the conversation's worktree as files its Git ignores, as yours does; above 32 MiB they keep
+  arriving after the agent has your prompt. The device helper finishes them while the VM is awake. A file the agent
+  writes first is kept.
+- **History from origin.** A project whose cache holds none of its history takes it from origin inside the cloud: the
+  fetch the VM makes of the branch while it boots (coding 53+), or one of its own; only commits origin lacks go from
+  this computer.
+- **Selected projects, prepared ahead.** `shard projects sync add <path>` keeps a project ready for new chats: the
+  device helper puts its current state in the project cache, and when its dependency files change, installs them and
+  saves the project template, each time in a short-lived VM it deletes after. `pause`, `remove` and `list` manage the
+  selection. Only selected projects are prepared.
+- A Codex Cloud start that outlives the launcher's deadline is not lost: the conversation stays accepted, and opening it
+  (or the device helper) continues the same start, with the state it captured, and sends the prompt once.
+- Uses SDK 0.26.0 (`projectTemplates.prepare`).
+- New conversations set the project up: in a repository whose project has no template for its current dependency
+  files, the conversation's VM prepares its worktree in the background (toolchains, dependencies, build and tests)
+  once the agent has its first prompt, and saves the project template the next conversation starts from, dependencies
+  installed. This covers `shard ./` in a terminal, with `--json` and opened in Claude Desktop or claude.ai, `shard agents
+  new` and the launcher.
+- Conversation previews and `shard ws tunnel` reach the guest on either loopback (SDK 0.26.0): a preview of a dev
+  server bound to `localhost` opens wherever the guest resolves localhost to `::1` first, and guest clients of
+  `localhost` reach a tunnel on the first try.
+- `shard agents accounts` suggests `use` only for accounts you can make active (the API's `can_activate`); a member is
+  told an owner or admin chooses the active account.
+- `shard agents accounts use <account>` makes an account the active one of its provider (`--json` prints the updated
+  list and the account). New conversations start with its login and running conversation VMs get it; running Claude
+  conversations bring Remote Control back by themselves, and Codex Cloud moves to the active ChatGPT account. The list
+  marks the active account `active`.
+- Removed: `shard agents accounts move`, `shard agents accounts pool`, `add --api-key-stdin` and `add --scope`. The
+  account you mark active stays active until you choose another; usage windows and status are shown for each account.
+- `shard agents open` and T3 Code no longer special-case pooled conversations.
+- The forwarder on this computer keeps your hosted CLIProxyAPI at one login per provider without waking it: at its
+  start, at the first request after the hosted copy slept, every minute while it sleeps and every 15 minutes while it
+  runs. A login chosen with `--use` on import arrives disabled and is enabled after the others are disabled.
+- `shard cli-proxy use <email|file>` makes a login its provider's active one in your hosted CLIProxyAPI (`--json` lists
+  the active and disabled logins). One login per provider serves requests, the others stay in the hub disabled, and
+  `shard cli-proxy` marks the active one. `--use <email>` on import picks it when this computer has several.
+
+- `shard machine save --wait` and `shard template save --wait`: a version larger than the plan's workspace disk says
+  so in plain words (its size and the plan's disk), with `retryable: false` and a hint that names both ways forward:
+  delete what the VM does not need (`shard machine open`), then save again, or move to a plan with a larger disk
+  (`shard billing plans`). It no longer suggests running the same save again or sending a bug report. The JSON error's
+  `details` add the build's `error_code` and its `limit`, `value` and `actual` (bytes). Any other save failure the same
+  VM cannot pass is `retryable: false` too. `shard machine setup --status` and the apps' machine row read it as too
+  large: "Cloud machine not saved: over the plan’s 2 GiB disk". Uses SDK 0.26.0.
+- Codex conversations open in your terminal app on macOS too, as Claude's do and as they already did on Linux:
+  `shard agents targets --open-in codex=terminal` (a bare `--open-in terminal` now covers both apps). The menu bar and
+  the Linux app offer it in each agent's **Open in**.
+- `shard agents targets --json` adds `open_in_targets`: every place each app's conversations can open on this computer,
+  so clients offer exactly what `--open-in` takes.
+- New conversations reach their first prompt sooner. The sign-in check and the conversation API check run beside the
+  project's local snapshot; this computer's changes are read while the VM starts; the repository's Git config, exclude
+  rules, branch and start-state snapshot take 4-6 fewer requests; credential fill is configured beside the first
+  prompt. With a VM whose platform has `sf-agent conversation first-prompt`, the VM types the first prompt itself, in
+  one request (it waits for the input box, pastes, waits for the paste to show, then presses Enter); `--json` still
+  reports `initial_prompt.submitted` the same way, and a prompt the VM could not type goes to the conversation's
+  inbox at once (`initial_prompt.queued`). When the VM has already fetched the repository's history from its remote
+  (platforms that start that fetch at boot), the seed adopts it and fetches only what is newer; the history apply and
+  the repository's config are one request, and the checkout writes files in parallel.
+- T3 Code: a new conversation's agent config from this computer is copied once its first prompt is on its way, as for
+  terminal conversations, and its agent starts with fewer serial steps (a prompt that opened the connection does not
+  reconcile the project files twice).
+- T3 Code: prompts in a repository with symbolic links are no longer refused with "mode changed during sync"; a link
+  is identified by its target on both sides.
+- T3 Code: a file edited on this computer before a conversation's first prompt reaches its VM as this computer's edit,
+  not a conflict: no `.shard-conflict-acp-…` copy lands in the checkout.
+- Each command starts ~0.1 s sooner: V8's compiled code for the CLI's modules is kept in the OS temp directory and
+  reused (Node's module compile cache).
+- `SHARDFLUX_TRACE_SEED=1` marks each start phase with its wall clock (`@<epoch ms>`) and runs to the first prompt's
+  Enter.
+- `shard conversations list`, `get`, `resume`, `wait` and `land` show **New conversation** for a conversation still
+  named by its generated id (it has not had a prompt yet), not the id a second time. A name you chose stays; `--json`
+  keeps the API's title.
+- `shard agents accounts` names every Codex window by its length, as the apps do: **Weekly**, **5-hour**, and **2-day**
+  or **90-minute** for other lengths (it read "Primary"/"Secondary" for anything but 5 hours and a week).
+- `shard ./` starts from a shallow clone (`git clone --depth N`): the conversation's repository gets the same shallow
+  history.
+- T3 Code ACP threads synchronize project files before each prompt and before reporting its completion. Remote edits, new files and deletions appear in T3’s Changes and checkpoints; local edits reach the next remote turn. Reopening retains the conversation’s sync baseline, including after a VM restore. Conflicting edits retain both copies using the existing project-sync rules. No idle file watcher is added.
+- `shard move` no longer asks for `--this-worktree-only` in a repository the live twin has snapshotted: Shardflux's own `refs/shard/*` refs are not counted as local refs the move would leave behind.
+- A conversation whose account setup cache cannot be mounted starts without a message in the terminal: setup caches in
+  the conversation's own workspace, as before, and the reason (API code, reason and request id) is a JSON line in
+  `setup-cache.log` of the config directory. `shard template` still reports `cache_scope`.
+- The editor sign-in also starts as `shard --login`, the form ACP registry clients run (they replace `acp` with the sign-in method's arguments); T3 Code's `shard acp --login` is unchanged.
+- Includes the desktop launch-card release: menu bar 0.8.3 and Linux desktop 0.1.8. Submitted prompts release the
+  launcher immediately and track startup independently in an overlapping card deck. Linux payload pins move to 0.1.8.
+- `shard operations progress <id>` reports actual suspension phase/deadline and safe next action. `shard operations cancel <id>` requests pre-capture cancellation; `--wait --timeout 5m` waits for confirmed original-workspace recovery. Acceptance remains distinct from recovery; a capture that has started is refused. Uses SDK 0.26.0 in this same batch.
+
+- **Breaking consent default:** `shard feedback` previews without sending; `--yes` submits only after review and explicit user authorization. Agent help and error nudges require user-directed reporting and preserve request/error IDs. Manual approved submissions, session fallback, validation, duplicate and rate-limit behavior remain supported.
+- Machine and template saves show source size and an estimated duration, then queued/build state and phase updates immediately. With `--json`, progress events go to stderr and the final stdout document includes `preflight` and `phases`. Failures flush the latest counters even within the update throttle and retain `details.last_progress` plus build/recovery pointers. Older APIs emit a structured `save_started` event when build progress cannot be read. Missing final host reports preserve the last observed progress.
+- Inspect separates `connections_ready` (legacy `ready`) from `machine_ready`. Failed saves, no saved version,
+  queue progress, older APIs and failed status checks stay visible. Unknown versions remain `null`; readiness
+  requires a positive saved version. Terminal onboarding names agent connections instead of claiming the whole
+  environment is ready. Conversations remain available while a machine is being set up.
+
+- **Your cloud machine as your account has it, everywhere:** `shard machine setup --status` reads the machine from your
+  account, so it always agrees with `shard machine`, and `shard setup --inspect` carries the same row
+  (`onboarding.machine`) next to your agents. It is ready (the version in use), saving (your agent setting it up, or
+  the save with its place in the queue), not saved with the reason in one line ("Cloud machine not saved: it’s too
+  large · version 2 stays in use") and what to run (`Save again`: `shard machine save --wait`, or `Retry`: `shard
+  machine setup --from-this-computer`), or not set up yet. The menu bar, the Linux app and the terminal's first run
+  show it. `--json` adds `machine: {state, version, line, reason, error, progress, action}`; `state` keeps its four
+  values (saving reads as `running`) and `machine_version` is the version in use.
+- `shard machine save` saves the machine VM that is there: a deleted one is skipped.
+- **On Linux, Linux words:** the first run's steps name the launcher shortcut you set in the Shardflux app (Alt+Shift+Space
+  unless you changed it), and every line and help text says "this computer" and "your computer".
+- **`shard move` follows where a session worked:** a session that began in another folder (such as Claude Desktop's
+  scratch folder) and went on in your repository is listed under the repository in `shard move --list` (and under the
+  folder it began in), `--last` picks it there, and `--path <repository>` moves it, with its working directories in
+  the repository moved to the VM's folder. A session's `cwd` is where most of its latest records are; `--json` adds
+  `cwds`, every folder it worked in.
+- A move confirms its repository from structured transcript metadata, including records between the discovery head
+  and tail. Nested tool inputs and outputs cannot confirm another folder; path rewriting preserves them and signed
+  history. Session listing accepts whitespace in JSON records.
+- The device helper also keeps its latest agent-config line ("Claude saved the skill deploy-checks in the cloud: it's on
+  this computer now") in `agent-config-notice.json` in the config folder, so the Linux app's top-bar panel shows it as
+  the Mac menu does (desktop-linux 0.1.8).
+- Pins `@shardflux/desktop-linux-x64` and `@shardflux/desktop-linux-arm64` 0.1.8.
+- **T3 Connect works in an account with more than one organization.** Every T3 sign-in (`shard setup --inspect
+  --t3-connect`, the onboarding and Settings, `shard agents open|new --in t3`) is scoped to an organization: `--project`
+  (id or slug), else a project of `--org`, else the API key's project, else the saved default project; the phone link
+  signs in for the workspace's own project. Before, a person in two organizations got 422 "project_id is required when
+  you belong to more than one organization" whatever they set.
+  Onboarding status uses the same person and project as sign-in, even when another organization is already
+  connected or no API key is saved. Its Connect command retains `--org`/`--project`; an explicit selection leaves
+  the default target's remembered status unchanged. A saved session or `SHARDFLUX_SESSION_TOKEN` starts sign-in.
+- **A default from an organization you left is said plainly.** `shard whoami` warns when the API key or the saved
+  default organization belongs to an organization you are no longer in, with the fix (`shard orgs use <org>`, `shard
+  setup --org <org> --new-key`); `--json` adds `warnings` (`code`, `message`, `fix`). Account commands name the gone
+  default and list your organizations instead of only "pick one with --org", and `shard setup` says the saved key's
+  organization is gone.
+- `whoami` also warns after switching defaults while a key belongs to another organization you still belong to.
+  Switch warnings distinguish a departed key from an accessible key elsewhere, retaining credentials until you
+  accept replacement. Environment keys take precedence; recovery names `unset SHARDFLUX_API_KEY`, and
+  `setup --json` includes an `api_key_environment_override` warning when the saved key is still overridden.
+- `shard orgs use` and `shard projects use` say when the API key acts in another organization (workspace, agent and
+  usage commands use the key) and name the command that makes a key for the new default; in a terminal they offer to
+  make it (`[y/N]`). `--json` adds `api_key` and `warnings`.
+- `shard usage --org <another organization>` reads it with your signed-in session (a project key answers 404 for any
+  other organization; `--org` also takes a slug when you are signed in). Without a session it says which organization
+  the key belongs to, with `shard auth login` and `shard setup --org <org> --new-key`.
+- Organization usage keeps a real 404 from the key's own organization, and a key in `SHARDFLUX_API_KEY` names the
+  `unset SHARDFLUX_API_KEY` step after saving a replacement. Summary, estimate and series use the same membership
+  checks; workspace usage keeps its project-key scope.
+- `shard setup` in more than one organization says how the choice is kept: the organization you pick becomes this
+  computer's default, with an API key for it, and `shard setup --org <org> --new-key` switches.
+- T3 Connect inspections keep permanent workspace link errors and their remediation visible, without restarting links or replacing an approved sign-in. After freeing a T3 environment slot, explicitly open the project in T3 again to retry.
+- Clarify machine save source selection and recovery: save from the machine VM, or explicitly select an existing
+  machine source with the SDK/MCP. A conversation or unmarked fork returns `filesystem_source_mismatch`; copy
+  intended changes into the machine VM before saving. Native VM access stays bound to its own workspace.
+- `shard move --plan` reports registered worktree paths, transcript reference hits, file counts and bytes before
+  upload. `--preserve-all-worktrees` copies all local refs and registered worktrees, including ignored files, with
+  exact indices, staged/unstaged status and hash checks; Git location pointers and transcript path fields map to
+  the VM. The selected tree uses the conversation branch; original branches/HEADs stay in a durable, immutable
+  migration-time recovery archive. Recovery refuses nonempty folders. `--this-worktree-only` explicitly leaves
+  other trees local. Source files, indices, refs and unrelated sibling folders stay untouched.
+- `shard update` keeps its npm prefix in the displayed install command. A permission failure offers an explicit user-directory install and executable path, leaving npm config, PATH and other packages unchanged; it no longer recommends sudo.
+- Machine setup requires a completed successful VM command and a structured setup report before saving. A refused
+  agent-config copy stops setup instead of publishing a machine without that configuration. An explicit Claude
+  Code tool permission refusal stops without trying another agent; ordinary connectivity or agent failures can
+  still fall back.
+- The setup agent receives the machine's actual disk grant and its limiting source before installing tools. It checks
+  available space and package sizes, uses small batches without recommended packages, and reports tools that do not
+  fit as skipped. It never changes your plan or disk caps.
+- Agent-led setup stops an action refused by a permission system or auto-mode classifier and gives the user an
+  exact command plus a non-secret confirmation to resume. It never bypasses the refusal through permission
+  changes, scripts or alternate tools. `setup --guide --json` checks saved account state without printing a key;
+  an exit code or a saved key alone is not evidence that onboarding worked.
+
+- **Start a project over from your machine** with `shard template delete`: the project template of this folder's
+  repository and its saved versions go, it is no longer rebuilt when your machine or the platform changes, and new
+  conversations start from your machine until setup after `shard ./` (or `shard template save`) saves a new one. VMs
+  running on it keep their files; builds still running for it are stopped. In a terminal it asks first (`[y/N]`, No
+  keeps it); elsewhere it needs `--yes`. It prints `template: deleted (3 saved versions); new conversations start from
+  your machine until setup saves a new one`, and `--json` the API's body (`template.versions`, `canceled_builds`).
+  Nothing saved for the repository is exit 3, `not_found` (`details.reason` `filesystem_not_found`).
+- `shard template` says when a template no conversation, VM or save used for 30 days follows your machine on its next
+  use (`platform …@4, follows your machine on next use`): it is rebuilt when a conversation starts on it, and that
+  conversation's VM moves onto the rebuilt version at its next safe point.
+- The agent-config loop follows activity: every 2 s while one of your conversations works or ended a turn in the last
+  5 minutes, backing off to every 60 s otherwise, with one small request every 10 s that snaps it back when a
+  conversation starts working anywhere (staging: 1.1 s p50, 2.3 s max over 6 turns; idle, 9.7 requests a minute
+  instead of 54 with 0.20.0).
+- **Your coding agent runs the setup; you only decide.** `shard setup --guide` (and `shard` in a coding agent's shell)
+  now tells the agent to do every step itself, ask one multiple-choice question at a time with the recommended answer
+  first, and keep each message to a sentence or two. It sets your cloud machine up from this computer by default (`shard
+  machine setup --from-this-computer`), asks where conversations open, and ends by opening your first conversation;
+  `--json` carries `rules` and each step's `choices`.
+- **Secrets without your agent seeing them:** `shard secrets create NAME --ask` (and `rotate`) opens a one-time page on
+  this computer where you type the value; it goes straight to your project's secrets and the agent only sees that it
+  was saved. In a coding agent's shell this is the default when nothing is piped; on a terminal you get a hidden
+  prompt. `shard files write <key> <path> --ask` does the same for a secret file such as `~/.npmrc` on your machine.
+  `--json` prints `{"event":"open","url":…}` first; the page closes after one use or 10 minutes.
+- **Claude sign-in from your coding agent:** `shard agents credentials login claude` runs in a coding agent's shell
+  (or with `--json`): it opens the claude.ai sign-in and a page for its code in your browser, then finishes by itself.
+- **Conversations open in your app:** `shard agents targets --terminal <ghostty|iterm|terminal|wezterm|kitty|alacritty|warp>`
+  (`:tab` or `:window`) saves where terminal conversations open, and `agents targets --json` lists the terminals on
+  this computer (`terminals`, the one shard runs in as `current_terminal`). `shard agents open <ref> --in terminal`
+  opens a new tab in that app (Ghostty 1.3+, iTerm2, WezTerm, kitty, Warp; a window in Terminal and Alacritty) in the
+  project folder, and `shard ./` from a coding agent's shell opens the new conversation there. When the app can't be
+  driven it opens the next one and says why in one line.
+- When a browser can't be opened, commands print the link to open instead (the opener's failure is detected).
+- Installs desktop-linux 0.1.8 on Linux.
+- **Mark your cloud conversations your way:** `shard settings --title-prefix <text|none|default>` sets the marker your
+  Claude conversations' titles start with in claude.ai and the Claude app (default `☁`: "☁ Fix login bug ·
+  todo-app"; `none` for no marker). `shard settings` shows it with where conversations open; `--json` too. New
+  conversations and threads you start on an existing computer carry it.
+
+## 0.20.0 (2026-10-12)
 
 - **A save waits in line instead of failing** when your plan's build slots are in use: `shard machine save` and `shard
   template save` print where the build is (`machine: saving version 5; queued behind 3 builds · about 40 s; …`), with