Repository navigation
Notifications say 100+ unread when the server's cap is reached - #799
Conversation
The server returns at most 100 unreads and pages only read items. A full unreads list now reads as "100+ unread", JSON gains unreads_capped, and --page says it pages read notifications only.
github-actions
Bot
added
commands
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The agent guidance incorrectly says reaching 100 proves additional unread notifications exist.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Clarifies the server’s 100-unread notification cap across output, JSON, help, and agent documentation.
Changes:
- Marks capped counts with
+and addsunreads_capped. - Explains that pagination only affects read notifications.
- Adds coverage for capped and uncapped responses.
[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or rungh pr ready --undo.
Click "Ready for review" or rungh pr readyto reengage.
| File | Description |
|---|---|
skills/basecamp/SKILL.md |
Documents unread limits and pagination behavior. |
internal/commands/notifications.go |
Adds cap-aware output and metadata. |
internal/commands/notifications_test.go |
Tests cap reporting and pagination guidance. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f31940b387
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Exactly 100 unreads also reach the cap, so unreads_capped marks a lower bound. Name 'notifications list --page' in the agent note, since the bare command has no --page. Preallocate the test fixture slices for prealloc.
|
@codex review |
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
What
notifications listno longer reports a capped unread list as a count.100+ unread, and the page total gets the same+:150+ notification(s) (100+ unread). A notice says the server returns no more than 100 and--pagedoes not reach the rest.data:unreads_capped(always present,trueat the cap). Every existing field keeps its name, place and shape; the result is the SDK struct embedded in a wrapper with that one extra field.--pagehelp, thelistlong help, the agent notes, and the "next" breadcrumb now say--pagepages read notifications only and every page repeats the same unreads.skills/basecamp/SKILL.mddocuments the cap and the flag.Why
The server returns at most 100 unreads (
MAX_UNREADS = 100in bc3'sMy::ReadingsController, and documented in the API) and pages only read items. The CLI printedlen(unreads)as the unread total and its "Next page" breadcrumb implied the whole feed pages, so an account with 235 unreads showed "100 unread" on every page.This is step 1 only. Reaching every unread needs a bc3 API change (an uncapped unreads endpoint), tracked separately; nothing here tries to page past the cap.
Testing
100+,unreads_capped: true, a notice, and unchangedunreads/readsarrays; 99 unreads give the exact count,unreads_capped: falseand no notice; the--pageusage and the next-page breadcrumb say read notifications only.make -k checkcompared against a cleanorigin/mainworktree on the same Mac: the same targets fail on both (lint: five pre-existing darwin gosec/unconvert/unused findings; test: pre-existing TTY/interactive and connector timing failures). The only difference isTestNoErrorPathCarriesTheSecretOutandTestAnAgentThatStopsReadingCannotHoldCancelOrCloseininternal/connector/driver/claude, which this change does not touch and which fail onorigin/maintoo when rerun. Every other target (e2e, surface, skill drift, naming, provenance, tidy) passes.Summary by cubic
notifications listno longer presents the server's 100-item unread cap as an exact total. When the cap is reached, the summary reads "100+ unread", JSON addsunreads_capped: truemarking 100 as a lower bound, and a notice explains that--pagedoes not reach the rest.skills/basecamp/SKILL.mdnow state that--pagepages read notifications only and every page repeats the same unreads.Written for commit b081173. Summary will update on new commits.