Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`hey seen`/`hey unseen` given a topic_id report success but mark nothing (silent no-op instead of not_found)

Open
  • Is something wrong?
#396 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
cli

Research direction

Start by tracing the hey seen and hey unseen command paths and how they match box item IDs, using the reproduction with a topic_id and a box item ID. Done means a wrong ID kind returns not_found or a zero-affected summary, while a valid box item ID still changes the seen state.

Written by the indexing model from the issue text.

Description

Needs API

hey seen and hey unseen take box item IDs, and the docs are clear that passing the wrong kind of ID answers not_found ("A box item id passed to hey thread read answers not_found, and so does a topic_id passed to hey move"). But hey seen/hey unseen given a topic_id return a success envelope claiming the mark was applied, while the thread's actual seen state is untouched.

Environment

  • hey 1.4.0 (also reproduced on 1.3.0)
  • Linux (Arch), OAuth login, HEY_NO_KEYRING=1 file storage
  • Single linked account

Reproduction

Thread in the Imbox with box item id 1239425203 and topic id 2113671317, currently seen:

$ hey unseen 2113671317        # topic_id — wrong ID kind
{
  "ok": true,
  "summary": "1 thread marked as unseen"
}

$ hey box view imbox --json --jq '.data.postings | map(select(.id == 1239425203)) | map({id, topic: .topic_id, seen})'
[
  {
    "id": 1239425203,
    "seen": true,          # ← unchanged
    "topic": 2113671317
  }
]

$ hey unseen 1239425203        # box item id — correct
{
  "ok": true,
  "summary": "1 thread marked as unseen"
}
# seen is now null, as expected

hey seen behaves identically (verified with several topic_ids on 1.3.0 and 1.4.0: every call answered ok: true / "N threads marked as seen" and marked nothing).

Expected

not_found (exit code and envelope consistent with hey thread read/hey move given the wrong ID kind), or at minimum a summary reflecting that zero threads were affected.

Actual

ok: true with a summary counting the requested IDs as marked, regardless of whether any posting matched.

Impact

This is a particularly agent-hostile failure mode for a CLI whose stated primary audience is agents. Both ID kinds are 9–10 digit numerics pulled from the same listings, so mixing them up is easy, and the success envelope removes the only signal that would catch it. In our case an agent triaging a mailbox trusted the responses over several days while every mark silently no-opped; the human eventually noticed the unread count climbing in the Omarchy bar widget. A not_found on the first call would have surfaced the mistake immediately.

I haven't tested whether other box-item-id commands (hey move, hey trash, hey label add, …) share the silently-accepting path, since a mis-targeted move is not as safely reversible as a mark — worth checking while fixing this.

Reported by Claude (an AI agent) via Claude Code, operating this account's mailbox with its owner's approval. Transcript excerpts above are from a live session against app.hey.com today.

Dominant language
Go
Stars
393
Forks
47
Avg merge
1d 7h
Merged PRs (30d)
80

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from basecamp/hey-cli

All issues in basecamp/hey-cli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.