chore(master): release 0.22.0

[arcbox-labs]

🤖 I have created a release beep boop

0.22.0 (2026-08-06)

Features

• providers: resolve provider endpoints per agent (#424) (cd67dd9)

Bug Fixes

• lint: run single-threaded by default and share one command with CI (#416) (1fb5474)

---

This PR was generated with Release Please. See documentation.

[pullfrog]

✅ No new issues found.

Reviewed changes — verified this generated release-please PR against the release config, the tag-equality gate in CI, and the commit range it claims to cover.

• Version bump is internally consistent — .release-please-manifest.json ("." → 0.21.1) and apps/desktop/package.json (version → 0.21.1) move together, which is exactly what release-please-config.json requires via its extra-files json-path entry.
• Invariant 5 holds — .github/workflows/build-desktop.yml:141-147 hard-fails unless v${version} equals the pushed tag; 0.21.1 here lines up with the v0.21.1 tag that Finalize Releases will push. .github/scripts/release-automation.cjs:75-80 derives the same tag independently for the verifyDesktopRelease gate.
• No stale version left behind — a repo-wide grep for 0.21.0 on this branch returns only the historical CHANGELOG compare links. Root package.json stays at 0.0.0, correctly, since the workspace root is unversioned.
• Changelog is complete — the only commits since chore(master): release 0.21.0 are #416 (in the changelog), Add pullfrog.yml workflow (non-conventional message, correctly ignored), and doc: improve readme files (not a changelog section, correctly absent).

ℹ️ 0.21.1 ships a desktop build with no user-facing change

The sole commit behind this release, #416 (1fb5474), touches only .github/workflows/ci.yml, .gitignore, docs/DEVELOPMENT.md, root package.json scripts, and the new scripts/lint.mjs — nothing under apps/desktop or any package it bundles. Because it was typed fix(lint):, release-please promoted a lint-tooling change into a patch release, so every installed client will auto-update from releases.linkcode.ai/desktop for a behaviorally identical build and see "run single-threaded by default and share one command with CI" as the release note.

Nothing here is wrong and this is not a reason to hold the PR — it is a convention question worth a deliberate answer, since it will recur.

Technical details

# Tooling-only commits produce user-facing desktop releases

## Affected sites
- `apps/desktop/CHANGELOG.md:8` — the 0.21.1 entry is a developer-tooling note published as a
  user-facing release note.
- Not a defect in this PR's diff; the cause is upstream at commit-message time.

## Required outcome
- A decision on whether repo-tooling changes (`scripts/`, `.github/`, `docs/`, root `package.json`
  scripts) should be able to trigger a desktop patch release and an auto-update for every
  installed client.

## Suggested approach (optional)
- The low-risk lever is the commit type: `chore(lint):` for tooling-only changes leaves them out
  of the release entirely, whereas `fix:` maps to a patch bump plus a "Bug Fixes" changelog line.

## Open questions for the human
- Is `exclude-paths` in `release-please-config.json` (today only `apps/mobile`, `apps/webview`) the
  right place to encode this instead? I did not recommend it because I could not establish the
  semantics: release-please's docs describe the option only as "exclude commits from that path from
  processing" and do not say whether a commit is dropped when ALL or only ANY of its files match.
  Getting that backwards would silently suppress real releases, so it needs someone to trace the
  implementation before changing.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

ℹ️ The retarget is mechanically correct. One release-timing question before merge, and a retraction of my previous note.

Reviewed changes — since my review at e2b8df5c, this PR retargeted from 0.21.1 to 0.22.0 because #424 landed on master. The incremental diff is only the three version strings.

• Minor bump is the right call — release-please-config.json sets bump-minor-pre-major: true, so a feat pre-1.0 yields 0.22.0 rather than 1.0.0.
• Retarget is clean — the prior 0.21.1 changelog section was replaced rather than stacked; no orphan heading, and a repo-wide grep for 0.21.1 now returns nothing. Manifest, apps/desktop/package.json, and the changelog heading all agree on 0.22.0, so the v${version} == tag gate at .github/workflows/build-desktop.yml:141-147 still holds.
• Changelog covers the range — since 37f2f8c8 (release 0.21.0) master has #424 (Features ✓) and #416 (Bug Fixes ✓); Add pullfrog.yml workflow is non-conventional and doc: improve readme files is not a changelog section, so both are correctly absent.

ℹ️ Retracting my previous note: this is no longer a no-op release

My review at e2b8df5c said "0.21.1 ships a desktop build with no user-facing change." That was accurate for 0.21.1 and is wrong for 0.22.0 — please disregard it. #424 is now in the release, so the reasoning behind that note no longer applies and the fix:-on-a-tooling-commit convention point is a footnote rather than the headline.

ℹ️ 0.22.0 ships #424 with no soak time on master

cd67dd9 merged at 05:42:40Z and this release PR regenerated about a minute later. It is 45 files and +1381/−626, rewriting per-agent endpoint resolution and credential injection across claude-code, codex, opencode, and pi, and adding a field to the persisted account shape. Merging this release PR pushes that straight to every installed client through the R2 updater feed, where there is no rollback for persisted data.

I checked the two invariants most likely to fail silently here and both are handled correctly — WIRE_PROTOCOL_VERSION goes 72 → 73 with MIN_COMPATIBLE_WIRE_VERSION correctly untouched (the new endpointParams is additive), and endpointParams is .optional() so pre-upgrade accounts still parse. So this is a timing judgement for you, not a defect I found.

Technical details

# Release timing for #424

## Affected sites
- `apps/desktop/CHANGELOG.md:8` — the Features entry that makes this a minor release.
- `packages/foundation/schema/src/model/account.ts` (in `cd67dd9`) — adds optional
  `endpointParams` to `AccountSchema`; the shape of already-persisted accounts.
- `packages/foundation/providers/src/resolve.ts` (in `cd67dd9`) — the new per-agent
  `resolveBinding`, which decides whether a session starts at all.

## Required outcome
- A deliberate decision on whether #424 goes out now or gets manual exercise first, made with
  the knowledge that the desktop updater has no downgrade path for persisted account data.

## Suggested approach (optional)
- The highest-value manual check is the upgrade path #424 explicitly patches: an account
  created by the OLD add flow (which pinned `endpoint` onto catalog accounts) starting a codex
  session on an OpenAI account after upgrade. That path is covered by
  `fix(providers): keep pre-variant accounts working across the upgrade`, but it is the one
  behavior a fresh-profile test cannot reach.
- `release-desktop.yml` supports `workflow_dispatch` with `dry_run: true` for a signed build
  without publishing, if you want artifacts to test against before tagging.

## Open questions for the human
- Is same-day release of a freshly merged provider-path change the intended cadence here? If it
  is, this needs no action and the note can be closed.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[arcbox-labs]

🤖 Created releases:

• v0.22.0

🌻