[sinjab]

Problem

chats re-derives short IDs on every run (assignShortIds picks the shortest unique suffix per run), so a short ID captured earlier — in a script, a shell history, or an earlier command in the same session — can stop resolving with a bare Short ID '…' not found, even though the conversation is right there in the index.

Two aggravations in the same path:

• the conversations API returns duplicate rows for the same thread (different letter-prefixed display rows), so even a valid suffix can look ambiguous when the matches all point at one thread;
• conversely, in 1:1 threads every conversation ID embeds the current user's org GUID as its tail, so tails of that GUID match every 1:1 chat and must be reported as ambiguous, not silently picked.

Change

resolveConversationId now:

1. dedupes candidate matches by full conversation ID before counting them;
2. falls back to unique-suffix matching (≥ 4 chars, the same minimum chats uses) against both the assigned short ID and the conversation-ID body — stale short IDs and id tails still resolve;
3. on a genuinely ambiguous suffix, lists the matching conversations and exits instead of picking one;
4. still passes full IDs (containing :) through untouched.

The function is exported and accepts an injectable chat index (resolveConversationId(id, chats?)) for testing — no fs mocking needed.

Tests

9 new unit tests in tests/resolve-conversation-id.test.ts: passthrough, exact match, duplicate-rows dedupe, stale-short-id suffix fallback, shared-thread suffix, id-body suffix, ambiguous listing, miss exit, and the <4-char guard. 102 total, all green; biome check and tsup build clean.

Independent of #27 (touches a different region of cli.ts).

[sinjab]

Friendly ping — happy to rebase this onto current main if anything has drifted. I'm also sending a few follow-up PRs (#30–#32: --json output, HTML send, file attachments) built on this line of work; no rush, just letting you know they're coming.