Desktop release
Release through .github/workflows/release.yml. Preserve both updater formats: Tauri uses latest.json; legacy v0.0.49 clients use update.json.
Publication authority
- Only the repository author, GitHub user
leookun, may authorize a live release.
- Before any live mutation, require an explicit release instruction from the author in the current task and verify
gh api user --jq .login returns leookun.
- Treat all of these as publication actions: pushing a
v* tag, rerunning the release workflow, and publishing or editing a GitHub Release. Pushing a release commit to main only prepares the release and must never trigger publication by itself.
- Without that authorization, restrict work to inspection, local edits, validation, and a release-ready commit or branch. Do not infer publication permission from requests such as “prepare”, “check”, or “ready to release”.
- Never print, commit, or upload
.tauri/cursor-byok.key anywhere except the repository's TAURI_SIGNING_PRIVATE_KEY Actions Secret when the author explicitly requests that secret configuration.
- Never delete, replace, or move an existing tag or published Release without separate explicit authorization.
Version and GitHub Release policy
- Do not use GitHub prereleases. Keep
prerelease: false for every release and publish the completed release as Latest.
- Use
vMAJOR.MINOR.PATCH for a stable tag, for example v0.1.0.
- Use standard SemVer
vMAJOR.MINOR.PATCH-beta.N for a test tag, for example v0.1.0-beta.1. A beta is still a normal GitHub Release, not a GitHub prerelease. Make its title or body visibly say Beta.
- This normal-Release rule is required because both installed update clients resolve assets through GitHub's
/releases/latest/download/ path, which excludes GitHub prereleases.
- Windows beta builds must use the NSIS bundle. WiX/MSI rejects nonnumeric prerelease identifiers such as
beta.1; do not weaken the SemVer tag to accommodate MSI.
- Release only from a
v* tag whose commit is contained in origin/main. The tag must equal v<version> from the desktop manifests.
- Keep ordinary
main pushes and manual workflow dispatch disabled as release triggers. The author pushes the matching tag only after the release commit is present on origin/main.
- Never republish an already published version. Select a new version instead.
Release sources
Keep the desktop version identical in the manifests and their locks:
cursor-byok/
├── Cargo.lock
├── apps/desktop/
│ ├── package.json
│ ├── package-lock.json
│ └── src-tauri/
│ ├── Cargo.toml
│ └── tauri.conf.json
├── scripts/cursor-proto/proto/
│ ├── agent_v1.proto
│ └── aiserver_v1.proto
└── .github/workflows/release.yml
The two listed Proto files are required build inputs and must be committed. Keep the other locally extracted Proto files ignored unless the build starts depending on them.
Prepare and validate
Inspect git status, fetch origin/main, and preserve unrelated user changes. Confirm the release commit is based on the current remote head.
Choose stable or beta numbering explicitly. Update the desktop version in both manifests and lockfiles; do not change the independent cursor-server version merely to release the desktop app.
Confirm the updater public key in tauri.conf.json matches .tauri/cursor-byok.key.pub without exposing the private key.
Confirm TAURI_SIGNING_PRIVATE_KEY exists in GitHub Actions. TAURI_SIGNING_PRIVATE_KEY_PASSWORD must be absent when the local key has no password.
Confirm neither the intended tag nor Release already exists.
From apps/desktop, run:
npm run check
npm run tauri:build -- --debug --no-bundle
Validate the workflow YAML and inspect the staged diff. Ensure .tauri/, unrelated local files, and unrelated user changes are not staged.
Use the tauri-action@v1 input uploadUpdaterJson: true; includeUpdaterJson is not a valid v1 input.
Publish and verify
After the author explicitly authorizes publication:
- Commit only the reviewed release set and push it to
main. Confirm the release commit is present in origin/main; this push must not start the release workflow.
- Create the matching tag on that commit, for example
v0.1.0-beta.1, and push only that tag. This tag push is the publication trigger.
- Follow the triggered
Release desktop app run through completion. Report the run URL and stop on failure; diagnose locally before asking the author to authorize another live attempt.
- Verify
v<version> exists, is published rather than draft, has prerelease: false, and is the repository's Latest release.
- Verify the Release contains signed Tauri updater artifacts plus
latest.json, and the legacy platform archives plus update.json.
- For a beta, report clearly that it is a test version even though GitHub represents it as a normal Latest Release.
1---2name: release3description: Prepare, authorize, publish, troubleshoot, and verify Cursor BYOK desktop GitHub Releases. Use for version bumps, release tags, GitHub Actions release runs, updater manifests, signing, or release-readiness checks.4---56# Desktop release78Release through `.github/workflows/release.yml`. Preserve both updater formats: Tauri uses `latest.json`; legacy `v0.0.49` clients use `update.json`.910## Publication authority1112- Only the repository author, GitHub user `leookun`, may authorize a live release.13- Before any live mutation, require an explicit release instruction from the author in the current task and verify `gh api user --jq .login` returns `leookun`.14- Treat all of these as publication actions: pushing a `v*` tag, rerunning the release workflow, and publishing or editing a GitHub Release. Pushing a release commit to `main` only prepares the release and must never trigger publication by itself.15- Without that authorization, restrict work to inspection, local edits, validation, and a release-ready commit or branch. Do not infer publication permission from requests such as “prepare”, “check”, or “ready to release”.16- Never print, commit, or upload `.tauri/cursor-byok.key` anywhere except the repository's `TAURI_SIGNING_PRIVATE_KEY` Actions Secret when the author explicitly requests that secret configuration.17- Never delete, replace, or move an existing tag or published Release without separate explicit authorization.1819## Version and GitHub Release policy2021- Do not use GitHub prereleases. Keep `prerelease: false` for every release and publish the completed release as Latest.22- Use `vMAJOR.MINOR.PATCH` for a stable tag, for example `v0.1.0`.23- Use standard SemVer `vMAJOR.MINOR.PATCH-beta.N` for a test tag, for example `v0.1.0-beta.1`. A beta is still a normal GitHub Release, not a GitHub prerelease. Make its title or body visibly say Beta.24- This normal-Release rule is required because both installed update clients resolve assets through GitHub's `/releases/latest/download/` path, which excludes GitHub prereleases.25- Windows beta builds must use the NSIS bundle. WiX/MSI rejects nonnumeric prerelease identifiers such as `beta.1`; do not weaken the SemVer tag to accommodate MSI.26- Release only from a `v*` tag whose commit is contained in `origin/main`. The tag must equal `v<version>` from the desktop manifests.27- Keep ordinary `main` pushes and manual workflow dispatch disabled as release triggers. The author pushes the matching tag only after the release commit is present on `origin/main`.28- Never republish an already published version. Select a new version instead.2930## Release sources3132Keep the desktop version identical in the manifests and their locks:3334```text35cursor-byok/36├── Cargo.lock37├── apps/desktop/38│ ├── package.json39│ ├── package-lock.json40│ └── src-tauri/41│ ├── Cargo.toml42│ └── tauri.conf.json43├── scripts/cursor-proto/proto/44│ ├── agent_v1.proto45│ └── aiserver_v1.proto46└── .github/workflows/release.yml47```4849The two listed Proto files are required build inputs and must be committed. Keep the other locally extracted Proto files ignored unless the build starts depending on them.5051## Prepare and validate52531. Inspect `git status`, fetch `origin/main`, and preserve unrelated user changes. Confirm the release commit is based on the current remote head.542. Choose stable or beta numbering explicitly. Update the desktop version in both manifests and lockfiles; do not change the independent `cursor-server` version merely to release the desktop app.553. Confirm the updater public key in `tauri.conf.json` matches `.tauri/cursor-byok.key.pub` without exposing the private key.564. Confirm `TAURI_SIGNING_PRIVATE_KEY` exists in GitHub Actions. `TAURI_SIGNING_PRIVATE_KEY_PASSWORD` must be absent when the local key has no password.575. Confirm neither the intended tag nor Release already exists.586. From `apps/desktop`, run:5960 ```bash61 npm run check62 npm run tauri:build -- --debug --no-bundle63 ```64657. Validate the workflow YAML and inspect the staged diff. Ensure `.tauri/`, unrelated local files, and unrelated user changes are not staged.668. Use the `tauri-action@v1` input `uploadUpdaterJson: true`; `includeUpdaterJson` is not a valid v1 input.6768## Publish and verify6970After the author explicitly authorizes publication:71721. Commit only the reviewed release set and push it to `main`. Confirm the release commit is present in `origin/main`; this push must not start the release workflow.732. Create the matching tag on that commit, for example `v0.1.0-beta.1`, and push only that tag. This tag push is the publication trigger.743. Follow the triggered `Release desktop app` run through completion. Report the run URL and stop on failure; diagnose locally before asking the author to authorize another live attempt.754. Verify `v<version>` exists, is published rather than draft, has `prerelease: false`, and is the repository's Latest release.765. Verify the Release contains signed Tauri updater artifacts plus `latest.json`, and the legacy platform archives plus `update.json`.776. For a beta, report clearly that it is a test version even though GitHub represents it as a normal Latest Release.