Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/mailfathom/issues.md or /mcp/mailfathom/issues.json, or Pod over MCP.

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.

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 · 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:

Read the thread · 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

Read the thread · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 2026-08-23 · closed · 0 comments

The remaining reports are on the project's issue tracker.