# Reported issues for apple-mail-mcp by parasxos

Pod holds 5 of 5 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to [apple-mail-mcp by parasxos](/mcp/apple-mail-mcp-by-parasxos).

## Most discussed

### Permanent wedge: "SQLite objects created in a thread can only be used in that same thread" on every DB-backed tool until restart

## Symptom

After some minutes of normal use (reliably right after a long `triage_apply`, ~40 s for 150 messages), every DB-backed tool (`search_emails`, `list_recent`, `get_email`, `get_thread`, `list_mailboxes`, `triage_plan`) returns:

```
ok: false, code: internal_error
ProgrammingError: SQLite objects created in a thread can only be used in that same thread. The object was created in thread id 6198554624 and this is thread id 6215380992.
```

The thread ids stay identical on every later…

[Read the thread](https://github.com/parasxos/apple-mail-mcp/issues/5) · 2026-09-13 · closed · external user · 0 comments

### triage_apply: allow excluding items from a reviewed plan

Today triage_apply takes only a plan_id and applies the whole plan. Reviewing a 40-message plan and wanting to drop one or two means narrowing the query or splitting the batch and planning again.

Proposed shape, open for input:

- exclude: list of envelope IDs on triage_apply, skipped at apply time and recorded in the receipt and audit ledger
- or ids: explicit envelope ID list on triage_plan, so a plan can be built from a reviewed selection instead of a query

Raised by a user on r/MCPservers…

[Read the thread](https://github.com/parasxos/apple-mail-mcp/issues/4) · 2026-09-10 · open · 0 comments

### Store-access health: surface FDA loss as state, not per-call errors

## Summary

On 2026-08-12 a `reply_email` call degraded to a plain `send_email` (thread lost, reply-all recipients lost) because the server process could not read the Apple Mail store. The per-call error was correct and actionable, but nothing aggregated four days of identical failures into a *state*, so the degradation stayed invisible until the first call that actually needed the store. `doctor` would have caught it — but only if someone thought to run it.

This issue proposes turning store…

[Read the thread](https://github.com/parasxos/apple-mail-mcp/issues/3) · 2026-08-12 · open · 0 comments

### FTS `docs` ledger silently deletes rows for messages still live in the Envelope Index

**Version:** email-mcp 0.11.0 (`0a721d8`)
**Component:** `email_mcp/fts.py`

## Summary

Rows are being deleted from the `docs` ledger for messages that still exist in the Envelope Index with `deleted = 0` and a resolvable mailbox. The count grows over time and does not self-correct, because `_crawl()` only covers rowids above the high-water mark and `reconcile()` only runs every `fts_reconcile_days` (default 7).

## Evidence

```sql
ATTACH '…/Envelope Index' AS env;
SELECT (SELECT COUNT(*)…

[Read the thread](https://github.com/parasxos/apple-mail-mcp/issues/2) · 2026-07-31 · open · 0 comments

### FTS body index: `missing` is permanent for non-cached Exchange accounts but treated as retryable, with a remedy that cannot work

**Version:** email-mcp 0.11.0 (`0a721d8`)
**Environment:** macOS 26.5.2, Apple Mail V10, Python 3.11.2
**Component:** `email_mcp/fts.py`, `email_mcp/sources/apple_mail.py`

## Summary

`email_mcp.fts` resolves message bodies exclusively from `.emlx` files on disk. When a file is absent, `_index_one()` records `docs.status='missing'` and the message's body becomes permanently unsearchable. The module treats this as a transient condition to be retried.

For a large Exchange/EWS account it is not…

[Read the thread](https://github.com/parasxos/apple-mail-mcp/issues/1) · 2026-07-31 · open · 0 comments

## Most recent

The remaining reports are on [the project's issue tracker](https://github.com/parasxos/apple-mail-mcp/issues).