Skip to content

Feature request: CLI commands to move postings between boxes (Paper Trail, Feed, Set Aside, Reply Later) #138

Closed

Description

@Janita-S

I love using Hey Email, there is nothing else like it.
I've tried using hey-cli with an AI agent (Hermes) to help manage my Imbox, and we've hit a wall — the CLI has no way to move a posting to Paper Trail, Feed, Set Aside, Reply Later, or Bubble Up.

The TUI has keyboard shortcuts for all of these (p, d, a, l, B, t), and the SDK has the methods (MoveToPaperTrail, MoveToFeed, etc.), but there are no corresponding CLI commands exposed for agents or scripts to use.

For AI-assisted email management this is a significant gap — I can ask my agent to triage my Imbox, but it can only mark things as seen. All the sorting still has to be done manually in the app.

Would love to see something like:
hey move trailbox, hey move feedbox, hey move asidebox ,hey move laterbox, hey move bubblebox, hey move trash

Note that Issue #74 covers Bubble Up specifically — this is a broader request for all the move actions. Happy to see them combined if that makes more sense.

Thank you!

Activity

  1. josh256 commented on Jul 21, 2026

    @josh256

    It would be great to add this; it's needed and would be a great improvement.

  2. added 2 commits that reference this issue on Jul 30, 2026
    b7a8d4f
    9b2577c
  3. martinlaws commented on Aug 5, 2026

    @martinlaws
    Contributor

    Hit the same wall, and went digging for why.

    The SDK methods are there, but the routes behind them are gone. MoveToPaperTrail, MoveToFeed, MoveToSetAside, MoveToReplyLater and MoveToTrash all resolve to /postings/{id}/move/{box}.json and /postings/{id}/trash.json in hey-sdk v0.3.0, and every one of those returns 404 against a live account today. So does GET /postings/{id}.json. The whole per-posting namespace looks retired.

    It isn't an auth or an ID problem: the same posting ID succeeds on POST /postings/seen.json with the same token, seconds apart.

    What does work is the route the web app itself uses:

    POST /postings/moves?box_id={boxId}
    Authorization: Bearer <token>
    {"posting_ids": [...]}
    

    200, with a turbo-stream body carrying one <turbo-stream action="remove" target="posting_{id}"> per posting that actually moved. Box IDs are per-account, so it needs a GET /boxes.json first, and it's a batch endpoint rather than one posting at a time.

    Worth flagging that #152 is built on those same SDK methods. I checked the branch out and ran it against my own account: feed, paper-trail, set-aside and reply-later all 404 (exit 2). I didn't test trash or ignore. Nothing wrong with the shape of it, just the plumbing underneath.

    All of this is against a single account, so if these routes are working for anyone else I'd genuinely like to know — that would point at scope or a rollout rather than a removal.

    I have a working implementation on the bulk route and can open it if that's useful. Equally happy to hold if you'd rather settle the route question first.

  4. robzolkos commented on Aug 25, 2026

    @robzolkos
    Collaborator

    Closing — hey move <box-item-id> --to <box> shipped and accepts Feed, Paper Trail, Set Aside, Reply Later, Trash (by name, kind, or ID), so agent-driven triage can sort, not just mark seen. The one deliberate exclusion is Bubble Up, since it needs a scheduled date — that's tracked in #74, which stays open. Thanks for laying out the agent use case so clearly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions