Repository navigation
fix(session): keyring hint names a locked keyring; build on cli-core 0.642.0 - #954
Merged
Merged
Conversation
…of reach The error for a profile that has logged in but cannot read its token sent the owner to cron and XDG_RUNTIME_DIR. On 2026-11-11 the cause was a keyring still locked right after boot (Secret Service: unlock prompt was dismissed), which the timer's run already waits out. The error and doctor now name that case first and keep the cron/ssh advice. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A daily or one-off schedule now sits out a rate_limited wait of up to 6 hours and runs once more instead of failing for the day. Also carries 0.642.0's local-only model switch and the downloaded speech model first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merged
leemour
added a commit
that referenced
this pull request
Nov 11, 2026
## Task Prepare max 0.111.0: #953 (cli-core 0.638.0 → 0.641.0) and #954 (keyring hint, cli-core 0.641.0 → 0.642.0). **Do not merge yet.** The live check of `messages sync --all` waits for the owner, and the changelog waits for his yes. ## Why - The headline fix is progress after every page in `messages sync --all`: WireCat Desktop showed «Чат 1 из 36 · 0» for minutes. Each progress line is now also a `sync.progress` event in `runs show`. - A daily or one-off schedule that gets `rate_limited` waits up to 6 h and runs once more. - 0.111.0, a minor: the section has entries under «Изменено — может сломать скрипты». npm's latest is 0.110.0. ## What - `package.json` and `src/version.ts` at 0.111.0. - `CHANGELOG.md`: `## 0.111.0 — 12.11.2026`, the `changes/` fragments collected as `bin/release` does, the two cli-core lines merged into one (0.638.0 → 0.642.0; the store stays at version 66). Completed from cli-core 0.640.0–0.642.0 with what a `max` command shows: name patterns and more candidates, `*part*` limits, a word's start in transcripts and file text, plain http refused for remote embeddings, `list:` refused, test people hidden. - The schedule entry now says daily and one-off only. Dropped the voice-order sentence: max has no MAX speech service, it always transcribes on this computer. - `docs/troubleshooting.md`: a token that does not read is first a keyring locked after boot, as the error says now. - `docs/commands.md` regenerated with no change. ## Testing - `pnpm release:check` on this branch: all 15 checks `ok` (exit 0), started 2026-11-11T23:00:10Z at ce5db99. A first run at 58ad42d failed only `tree unchanged` — the docs fix made while it ran. - Live, **waiting for the owner** (read-only, `default` profile, the release build through `bin/max`): 1. `bin/max default messages sync --all --since-time 2d --no-catch-up --json` (ends by itself). On stderr, a `{"event":"progress","step":"sync",...}` line after every page, 5–10 s apart, with `fetched` growing inside a chat before `chats_done` moves on. 2. `bin/max default runs list --limit 10 --json`: take the sync run's `run_id`. 3. `bin/max default runs show <run_id> --json`: `sync.progress` events with `counts`. - `smoke:live` not needed: no write path changed. The release report in cli-private has the proposed one-word script. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task
The owner's nightly
max defaultsync failed on 2026-11-11 and asked for scheduled syncs that recover by themselves and say what is wrong.Why
XDG_RUNTIME_DIR. The real cause was a keyring still locked right after boot (Secret Service: unlock prompt was dismissed), which the timer's run already waits out.rate_limitedfailed for the day (fixed in cli-core 0.642.0, fix(schedule): a daily run sits out a rate_limited wait and runs once more cli-core#2872).What
session.tsanddoctor: "the keyring is probably locked or out of reach (right after boot it opens at your login, and a timer's run waits for it; from cron or ssh, set XDG_RUNTIME_DIR)".@wirecat/cli-core0.641.0 → 0.642.0; changelog fragmentchanges/fix-keyring-hint.md.Testing
pnpm typecheck,pnpm lint,pnpm build,pnpm lint:commands,pnpm generate(no doc change),pnpm docs:check.pnpm vitest run— 1,632 passed, 7 skipped.🤖 Generated with Claude Code