@shardflux/cli 0.20.0 → 0.23.0

package/CHANGELOG.md

@@ -1,6 +1,317 @@
 # Changelog
 
-## 0.20.0 (not yet published)
+## 0.23.0 (2026-10-14)
+
+- Codex Cloud enable and setup report when a ChatGPT sign-in is required, with `codex login` and `shard setup` as the next steps. Setup offers the sign-in action.
+
+- On macOS, the installed CLI records a matching stable Node.js path for the menu bar, so Homebrew upgrades and
+  cleanup keep its actions available.
+- On Linux, the desktop records the installed Node.js and CLI paths for its actions and existing autostart entry,
+  keeping them available after the launching shell's fnm multishell links expire.
+- Opening a moved Claude or Codex conversation by its full key resolves the conversation from any folder, including
+  `--in auto` in the desktop menus and explicit app/web targets. A computer key opens its bound conversation's session.
+- Move to cloud moves the session's checkout, uncommitted edits included, in any repository: also one with other
+  local branches, other worktrees or a worktree whose folder is gone. Those stay on this computer, so `shard move`,
+  the menu bar's and the Linux app's **Move to cloud** and the MCP tool go straight ahead without a scope choice
+  (`--this-worktree-only` is now the default). When the session also worked in another worktree, the move names it
+  in one line and `--json` lists it as `other_worktrees`. `--preserve-all-worktrees` skips registrations whose folder
+  is gone (`stale_registrations` in `--plan`); their branches move with the other local refs.
+- Open Codex Cloud chats in the browser on every platform. `agents open --original` opens the original history; `--history <thread-id>` opens any earlier linked chat. JSON includes all previous history links.
+
+- Opening a conversation from a coding agent's shell (Codex, Claude Code, Cursor) opens exactly one terminal, and the
+  conversation attaches there. The terminal no longer inherits the agent shell's variables, and a terminal Shardflux
+  opened never opens another, so it no longer reopens terminals in a loop that steals focus. A Codex Cloud conversation
+  opens in Codex before any terminal is considered, also when given its computer's key.
+- Inherits completed forward-helper verification reuse from SDK 0.27.0 on a reused workspace client; each ownership epoch and helper version is verified again.
+- Historical template file-list GETs wait for checksum-verified cache reconstruction, honoring Retry-After within the SDK admission deadline. File history and contents remain stored; POSTs never replay for file_list_indexing.
+
+- Plan-derived API budgets (0.23.0+, SDK 0.27.0): `--json` error output includes `rate_limit` and `retry_after_seconds`; the text hint names the shared scope and delay. API request pacing follows the SDK admission timeout and preserves the request body. Reuse workspace credentials and reduce status polling when the returned budget asks for a delay.
+
+- T3 Code conversations on Shardflux follow your T3 Code proxy setup (CLIProxyAPI, or any Claude- or
+  OpenAI-compatible proxy). What your T3 Code Claude provider runs with (its environment variables, and Claude Code's
+  settings.json `env`: `ANTHROPIC_BASE_URL`, its token, models and headers) reaches the conversation's Claude Code, and
+  your Codex `model_provider` (its `base_url`, `wire_api` and the key `env_key` names) reaches its Codex. CLIProxyAPI
+  on this computer (`127.0.0.1:8317`, or the port it had before `shard cli-proxy import`) is reached through your
+  hosted CLIProxyAPI, as on this computer; a proxy at another address is used as written. A Claude Code conversation
+  that goes through your proxy with its own token starts without a Shardflux Claude sign-in. T3 Code's default
+  provider is the one followed while it is enabled.
+- `shard agents new --in t3` and `shard agents open t3` give the VM's own T3 Code (SSH and the T3 app) the same Claude
+  Code and Codex provider settings, with tokens in its secret store.
+- Sign in on the Shardflux provider in T3 Code (`shard acp --login`) offers to move the CLIProxyAPI your T3 Code setup
+  uses into your account, so cloud conversations use it too. Claude Code that goes through it is connected then.
+- Your hosted CLIProxyAPI routes requests across your logins exactly as its config says (round-robin, fill-first,
+  session affinity): `shard cli-proxy import` brings every login as it is on your computer, enabled or disabled, and
+  nothing changes them afterwards. `shard cli-proxy use <login>` serves a provider with that one login; `shard
+  cli-proxy use --all` uses every login again. `--use` on import is the same choice for a login you move.
+- `ws exec-cancel` displays pending/unverified kernel drain and the follow command; `exec-read` keeps the real foreground state and reason.
+- `shard template save` and `shard template` on your computer use the newest conversation this checkout started whose
+  VM is still there (a restored one too), else the project's workspace from before conversations. They no longer
+  refuse with "Run shard ./ for this project" after `shard ./`.
+- `shard agents logs <conversation>` of a Codex Cloud conversation says its output is in its Codex thread and names
+  the commands that show it: `shard agents open <id>` opens the thread, `shard c wait <id>` waits for its reply and
+  `shard c get <id>` shows it.
+- `shard agents new --in terminal --prompt <text>` (or `--prompt-file`, `--image`) starts a new conversation with that
+  first message, as without `--in`; a new Codex conversation says it opens in Codex Cloud. Before, it was refused
+  with a message that recommended the same command. A first message with `--name`, `--like`, an agent argument or
+  another `--in` target names the option it cannot be combined with.
+- `shard projects sync add <path> --wait` reports a project setup that stopped as `project_setup_failed` (it was
+  `internal_error`): the message names the step and what it needs, such as a lockfile to commit,
+  `details.step` and `details.error_code` identify it, and the hint gives the way forward.
+- `shard agents open` (and Open in the menus) of a Codex Cloud chat that switching the active Codex account or turning
+  Codex Cloud off and on stopped continues it in a new Codex chat of the same conversation, on its computer and branch,
+  instead of reporting that its executor was removed.
+- ACP journal followers retry temporary lifecycle interruptions with bounded backoff and their saved sequence, without resubmitting a turn; permanent loss stops promptly.
+- SSH inherits the SDK cold helper race repair.
+- Inherits SDK 0.27.0 safe replay of truncated JSON lifecycle and exec answers.
+- Uses SDK 0.27.0: workspace exec retries a lost start response with the same session ID.
+
+- A T3 Code (`shard acp`) conversation starts the way a terminal one does: from its prepared revision, sending only
+  what the project cache lacks (nothing for a returning project), so its session is ready ~2.5–3 s sooner. Large files
+  still on their way stay out of the first file reconcile and land by themselves.
+- A T3 Code (`shard acp`) conversation's first prompt reaches the agent ~1 s sooner: the agent's session starts while
+  the project files are reconciled, instead of after. `SHARDFLUX_TRACE_SEED=1` also marks each step of that
+  connection (`acp_*`). Each message to the agent up to 192 KiB (every one but a long prompt) now takes one request
+  to your VM instead of four.
+- `shard agents open t3` and `shard agents new --in t3` with T3 Code 0.0.45 bring T3 up only once the workspace's T3
+  Connect link is linked: T3 lists the project only then. A link in progress is waited for (at most 30 s, within
+  `--wake-timeout`). A refused link is the `t3_link_failed` error with the API's remedy (for T3 Connect's environment
+  limit, Settings → Connections, with `details.recovery`); a link still in progress is `t3_link_pending`. Both carry
+  `workspace_key`, `conversation_id` and any started `t3_thread_id`, so the menu bar and the Linux app offer Open for
+  what exists rather than a new start. Before, `--json` answered `opened: true` with `t3_link.status: linking`.
+- `shard agents open t3 <conversation>` for a Codex Cloud conversation opens its existing Codex chat, as
+  `shard agents open` does, instead of setting its VM up in T3 Code, which cannot show that chat. It neither wakes the
+  VM nor needs T3 Code.
+- The Codex app on Linux: OpenAI's ChatGPT app for Linux (`chatgpt.desktop`) or a community build, found as the desktop
+  entry that handles codex://. `shard agents open <conversation>` and `shard agents open codex-app <conversation>` open
+  a Codex Cloud conversation's existing thread in it, through that entry, and `agents open codex-app` of a Cloud
+  conversation opens its thread on macOS too (it set up an SSH environment before). Its SSH environments stay a macOS
+  target.
+- On a computer without the Codex app, opening or starting a Codex Cloud conversation says where its chat is,
+  whether it is waiting for your answer, and how to answer and follow it from here (`shard conversations send <id>
+  "<answer>"`, `shard conversations get <id>`), instead of failing to open its codex:// link. `--json` adds
+  `codex_app` and `reply_command`.
+- The command center (`shard` with no arguments) lists a Codex Cloud chat as **needs you** or **working** from Codex
+  even while its computer is parked, and Enter opens it in Codex without waking that computer. Includes the Linux
+  desktop 0.1.10 payloads: Codex Cloud chats in the top-bar panel.
+- `shard menubar start`, `stop` and `status` act on the Shardflux app for this config directory wherever it runs from
+  (menu bar 0.8.4+, one app per config directory), and an update stops that app before the new one starts, so no
+  older app stays behind. A start that races another one for the same directory hands over without opening the
+  launcher.
+
+## 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