# Reported issues for MailFathom

Pod holds 24 of 156 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [MailFathom](/mcp/mailfathom).

## Most discussed

### Run the integration suite against main with the AI provider contract tests on, and repair what it reports

## Context

The integration suite never runs on a pull request. It starts a PostgreSQL container and an orchestration, so it is minutes of runner time rather than the seconds a pull-request check is worth, and it is reachable only by a manual dispatch of `Integration tests` or by `Release` calling it before it builds anything. That is the deliberate arrangement, and its known cost is that a change breaking the suite merges green and stays broken until somebody asks for a run.

The provider-contr

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/813) · 2026-08-13 · closed · 2 comments

### [P] Configuration-authored rules that act on synchronized mail

## Context

**No numbered specification under `specs/` backs this issue.** It records a capability the roadmap does not cover: letting the owner define recurring work of their own over synchronized mail, rather than only reading it through the MCP tools.

Two shapes are wanted, and the first decision is that they are not one feature with two backends:

- **Programmatic rules.** A deterministic definition — a condition over stored metadata and extracted text, then a bounded set of actions. Reprod

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/251) · 2026-08-01 · closed · 2 comments

### Publish MailFathom metadata to the official MCP Registry

I would like to request that MailFathom be added to this list.

Publish the current MailFathom release to the official MCP Registry using registry metadata that accurately represents an operator-hosted Streamable HTTP endpoint.

## User stories

- As an MCP client user, I want to discover MailFathom under an ownership-verified namespace so that I can identify the official server metadata.
- As a MailFathom operator, I want the registry entry to describe my deployment-specific `/mcp` endpoint wit

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/856) · 2026-08-14 · closed · 1 comment

### Advertise the scopes a client should ask for, separately from the ones a token must carry

## Context

`PublishedOAuthMetadata.For` composes `scopes_supported` as the distinct union of every configured entry's `RequiredScopes`. A deployment therefore advertises exactly the scopes it will refuse a token for lacking, and has no way to tell a client about a scope it should ask for but will not be checked on.

`offline_access` is that scope. `mfctl` is the only client that obtains a refresh token here, and it does so by disregarding what the deployment published: `DeploymentAuthorizer.Sco

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/816) · 2026-08-13 · closed · 1 comment

### [P] Manage owner mail rules at runtime through writable configuration

## What this feature is

Mail rules remain configuration. This feature makes one owner's `MailRules` section writable at runtime from `mfctl` and, only when explicitly enabled, from MCP.

#1119 and #1243 remove the expensive premise in the old design. PostgreSQL is not a second live rule authority and no dedicated `stored_rules` table is introduced: an owner's rules are typed content of that owner's `settings_accounts` document, written through #1243's writer port and read through an application

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/771) · 2026-08-12 · open · 1 comment

### Edit Trusted Senders through the writable configuration provider

## Context

#757 evaluates the trusted-sender list for one mail account. This issue makes that list editable, but it no longer builds a dedicated configured half plus stored half and unions them in a special reader.

#1119 is the single writable configuration mechanism. #987 stores one JSONB document per owner in `settings_accounts`, and that document contains the declarations for all mail accounts the owner owns. A mailbox's `TrustedSenders` list is edited at its path inside that owner document

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/760) · 2026-08-12 · closed · 1 comment

### Warn at the top of a message whose sender this deployment could not verify

## Context

The first transformation, and the reason the other three children exist: a message whose sender this deployment could not verify is presented with a warning at the top of its body, so the warning is read before the content is.

Most of what makes it right is wording. A banner that says *this message is dangerous* is wrong about nearly every message it appears on, and a reader who meets it on ordinary correspondence twenty times stops seeing it — which leaves the deployment worse off 

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/759) · 2026-08-12 · closed · 1 comment

### Enforce a send grant distinct from the read grant, in the listing as well as the call

## Context

Sending must require a grant of its own, distinct from reading. That distinction is the whole point: a client granted access to a mailbox for retrieval must not thereby be able to write from it, and the difference has to be enforced rather than documented. Draft section 13.5 says the same, and is superseded on *how* — see below.

Two things make this more than adding a string to a descriptor.

**The listing is part of the enforcement.** A caller without the send grant should not see 

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/745) · 2026-08-12 · closed · 1 comment

## Most recent

### Move the benchmark and mutation-score diagnostics from the nightly channel to a weekly pipeline

## Context

`Nightly` carries two jobs that publish nothing and gate nothing: `Hot-path benchmarks` and `Mutation score`. They sit there as passengers on a channel whose reason to exist is publishing an image of `main`, and they run only when that channel's publish decision says `main` has moved — a condition that belongs to the image, not to the two measurements.

The two diagnostics answer a slower question — what the hot paths cost, and where the suite stopped asserting — and a fixed weekly c

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1373) · 2026-08-30 · closed · 0 comments

### Dispatch issues to Claude Code or Codex with runtime-specific labels

## Context

The host dispatcher currently treats `agent:run` as one queue and replaces it
with the runtime-neutral `agent:claimed` marker before starting a Claude Code
session. Its capacity, snapshot, restore, shutdown, merged-PR reaping, and
frontend-tool selection all understand Claude Code state only. Codex already
has a supervised local app server, persistent interactive sessions, resumable
session IDs, compatible repository skills, plugin profiles, and worktree-aware
transcripts, but no iss

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1349) · 2026-08-28 · closed · 0 comments

### Record that a credential reaches every account its owner owns, and that narrowing it further is refused

## Context

[ADR 0014](https://github.com/Krzysztof318/MailFathom/blob/main/docs/decisions/0014-single-tenant-multi-user-ownership-on-the-mail-account.md) settles how MailFathom serves more than one person: one tenant, several owners, a mail account belonging to exactly one of them. It left one axis open — narrowing a single credential *within* its own owner's accounts — and pointed at #588 for it, in three places and by name.

That axis is now refused. `McpEndpoint` and `ClientEndpoint` resolve

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1313) · 2026-08-27 · closed · 0 comments

### Give the deployment one way to hold work exclusively, as a lease in PostgreSQL with no consumer yet

## Context

The decision this follows records what a lease is; nothing implements one yet. The job store leases a job, but its lease is a stamp on the job row and is reachable only through the job's own claim statement, so a supervisor, a sweep, and a content move have nothing to take. Each of the three lands in a different boundary and none of them should carry a coordination mechanism of its own.

What is missing is one application-owned port for taking, renewing, and releasing exclusive hold 

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1289) · 2026-08-25 · open · 0 comments

### Keep a message withheld from chat out of every MCP result, and refuse it by identifier as absent

## Context

#1258 lets the owner name the mail no model may be shown, #1259 compiles the set, and #1261 writes a verdict beside
each message. #1260 closes the two paths this deployment hands text to a provider on itself. This issue closes the
third, and the one where the model is somebody else's: the MCP surface.

**A tool result is a prompt this deployment did not compose.**
[`SensitiveContentEgressPoint`](https://github.com/Krzysztof318/MailFathom/blob/main/backend/src/Application/SensitiveCon

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1273) · 2026-08-25 · open · 0 comments

### Keep a withheld message out of chunking, embedding, and every retrieval that feeds a chat run

## Context

This is the half of #1258 that acts. #1261 gives every stored message a verdict naming the provider roles it is
withheld from; here each role's gate reads it, and what was derived from a message before the owner decided against it
is taken back.

**The embedding gate has a shape to follow rather than one to invent.** #693 put junk behind exactly this gate: a
withheld message is not cut into passages, is not offered to the embedding backlog, and its content never reaches a
provider, w

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1260) · 2026-08-24 · open · 0 comments

### Route each writable configuration path through a hard-coded catalog, and deny the bootstrap paths

## Context

#1119 puts a PostgreSQL layer under the operator's overrides and reads it. What it does not answer is where a value goes when something writes one, and that question cannot be answered per call: a path that could land in two places is a value with two truths.

A hard-coded catalog compiled into the program answers it. Paths nobody assigned a special route go into the singleton `settings_root` document. A path named by a special route is excluded from that document and projected from 

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1242) · 2026-08-24 · closed · 0 comments

### Store a secret in the database under the key ring, and reach it through a new secret-reference scheme

## Context

`SecretReference` resolves through four schemes today — `systemd-credential:`, `file:`, `env:`, and `plaintext:` — and each names something a deployment provisioned before the process started. That is right while every secret MailFathom holds is the deployment's own: a mailbox password in a mounted file, the key ring's material in a systemd credential.

Under #980 it stops being enough. An owner provisioned at runtime through #1224 supplies a mail-account password, and there is no fi

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1238) · 2026-08-24 · closed · 0 comments

### Instrument the client with traces, metrics, and logs on one OpenTelemetry pipeline

## Context

The client records nothing. `App.OnLaunched` configures `UseLogging` with a minimum level and Uno's core level, writing
to a console that exists in the developer loop and nowhere else; there is no `ActivitySource`, no `Meter`, and no
OpenTelemetry package in `frontend/Directory.Packages.props`. This is the pipeline, composed at the one point that is
already the client's composition root.

Two things about the browser head decide the shape rather than merely constrain it. It cannot sp

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1229) · 2026-08-24 · open · 0 comments

### Proxy OTLP out of the client endpoint, per signed-in person, and stay quiet doing it

## Context

`/api/client` serves one route today, and `ClientApiEndpoints` says why in its own remarks: the surface was published
with proof of life on it so the transport decisions could be reviewed before mail-reading routes stood on them. This is
the second route on it, and it is not a mail route — it is how the client hands the deployment telemetry it cannot
export itself.

It cannot export it itself for a reason worth stating rather than assuming. The destination's address and its credentia

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1228) · 2026-08-24 · open · 0 comments

### Provision owners through AdminEndpoint and mfctl, and let an owner maintain their own document

## Context

The deployment administrator is distinct from an owner. `AdminEndpoint` is the only externally reachable endpoint that can enumerate and provision owner records across the deployment; `McpEndpoint` and `ClientEndpoint` always map a request to exactly one owner row.

With #987's row in place and #1223 serving whichever owners a file declares, an operator still has no way to add or remove an owner, or one of an owner's mail accounts, while the process runs. This issue is that way in: t

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1224) · 2026-08-24 · closed · 0 comments

### Record every publication, grant, and role change, by reference rather than by value

## Context

Sharing private correspondence-derived knowledge is the point in this product where somebody becomes accountable for
a disclosure, and accountability without a record is a claim. The product asks for a **publication audit trail** and
for a visible **decision trail** — what the model did, what a deterministic rule did, and what a human approved.

The repository already has the seams for this: it requires explicit seams for data-subject workflows, audit evidence,
and accountable proces

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1199) · 2026-08-23 · open · 0 comments

### Grant one fragment, message, or file to one Case, and make revocation real

## Context

This is the child the whole stage exists for. Membership says who is in a Case; this says what they can actually see
of the mail behind it — and the answer is: only what the owner named, item by item.

The mechanism is already half built. Citation resolution answers *may this caller read this target* as part of
resolving, and returns a private source rather than an error when the answer is no. This adds the other half: a grant
that makes one specific fragment, message, or attachment 

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1198) · 2026-08-23 · open · 0 comments

### Serve lexical and semantic search with filters that constrain rather than rank

## Context

Finding mail is the client's whole premise, and the service already has both halves of it: PostgreSQL full-text
search over extracted text, and semantic retrieval over embeddings with hybrid ranking. What is missing is a
client-facing route, and the shape of that route is not the shape of the MCP tool.

A screen searches differently from a model. It searches as somebody types, it searches within a filter that is already
in force, it needs to say why each result matched so a person ca

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1158) · 2026-08-23 · closed · 0 comments

### Serve a thread as one document, across folders and accounts

## Context

The service already threads mail: conversations are derived and stored, and the MCP surface exposes them. The client
needs the same thing shaped for a screen — a thread as one document, with its messages in order and each carrying
enough to be drawn collapsed, rather than a list of message identifiers the client then fetches one at a time.

A thread is also where a mail client's hardest ordinary problem lives. A conversation spans folders and accounts: the
question is in the inbox, t

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1157) · 2026-08-23 · closed · 0 comments

### [P] Stage 1 — a client API for reading mail, shaped by what a screen does

## Context

`/api/client` answers one route, `GET /api/client/session`, and `docs/operations/client-endpoint.md` says the mail
routes are deliberately absent until they are designed. This parent designs them.

The design rule is the one thing worth stating before any route exists: **the client API is shaped by what the client
does, not by copying the MCP contract**. The two surfaces serve different callers. A model calls an MCP tool once with
a question and wants a bounded answer; a screen calls

[Read the thread](https://github.com/Krzysztof318/MailFathom/issues/1152) · 2026-08-23 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/Krzysztof318/MailFathom/issues).