Fixes from testing email search (docs/enhancements-2026-07-07.md):
- New `folders` agent command lists the account's mailboxes (name,
delimiter, selectable), INBOX first, so agents can discover archived
mail outside INBOX.
- `search --all-folders` sweeps every selectable mailbox; each hit
carries a `folder` field, `skipped_folders` reports mailboxes the
server refused, and --limit caps visible results across the sweep.
The sweep deliberately skips EnsureFolderBaseline so a read-only
search never mutates list --new state.
- Empty search results include a generic `data.hint` with next steps.
The hint is a fixed constant per mode, so the invisibility invariant
holds: absent and policy-filtered mail produce byte-identical
envelopes (codified in TestSearchEmptyHintIndistinguishableFromFiltered).
- Skill and user docs: document `--text` full-text search as
best-effort (server-dependent); recommend --subject-contains/--from.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
If header/body parsing errored mid-fetch we returned without draining the
message channel, so the UidFetch goroutine could block on a full channel.
Both fetch paths now break, drain remaining messages, then read the done
error. Verified with the race detector.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
list and search now fetch BODY.PEEK[HEADER] + BODYSTRUCTURE instead of the
whole RFC822 message, so listing a large mailbox no longer downloads every
message body and attachment. Header parsing reuses the same go-message path
(RFC2047 decoding/formatting preserved); has_attachments is derived from the
BODYSTRUCTURE tree. FetchFull keeps fetching the full message for get.
Validated end-to-end against a live IMAP account: list/search/get output
identical to the prior full-fetch behaviour, has_attachments correct.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Cap search results to limit (keep most-recent UIDs)
- Propagate io.ReadAll errors from body reads in fetchByUIDSet
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
steve