# Reported issues for ofw-mcp Pod holds 15 of 15 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 [ofw-mcp](/mcp/ofw-mcp). ## Most discussed ### Auto-review follow-ups for PR #253: docs: list the cache env vars in server.json and .env.example Tracking auto-review follow-ups for #253 (verdict: **warn**). ### 🟡 Nits - [ ] CLAUDE.md's Environment section should include OFW_SESSION_CACHE and OFW_SESSION_FILE for consistency --- Checklist regenerated from the auto-review of `bdb55a7` ([run](https://github.com/chrischall/ofw-mcp/actions/runs/33125882058)). Ticks survive later rounds, but a round that reviewed an older commit can still re-list something already fixed — check that SHA before redoing an [Read the thread](https://github.com/chrischall/ofw-mcp/issues/254) · 2026-08-27 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #244: feat: cache the session token so a restart skips re-authenticating Tracking auto-review follow-ups for #244 (verdict: **warn**). ### 🟡 Nits - [ ] src/client.ts:69-74 — stale doc comment on `tokenManager` field still describes the removed eager-placeholder-token seeding, contradicting the new comment above `mint` explaining why the function form is now required --- Checklist regenerated from the auto-review of `bb9e384` ([run](https://github.com/chrischall/ofw-mcp/actions/runs/32928722046)). Ticks survive later rounds, but [Read the thread](https://github.com/chrischall/ofw-mcp/issues/245) · 2026-08-26 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #232: refactor: drop the in-array truncation sentinel from ofw_list_messages Tracking auto-review follow-ups for #232 (verdict: **warn**). ### 🟡 Nits - [x] CLAUDE.md line 41 still lists `truncationSentinel` as a pagination.ts export in the architecture tree, though this PR removes that export --- Checklist regenerated from the auto-review of `a546788` ([run](https://github.com/chrischall/ofw-mcp/actions/runs/32666338202)). Ticks survive later rounds, but a round that reviewed an older commit can still re-list something already fixe [Read the thread](https://github.com/chrischall/ofw-mcp/issues/233) · 2026-08-23 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #185: feat(attachments): deliver readable content for every file type Tracking auto-review follow-ups for #185 (verdict: **pass**). ### 🟡 Nits - [ ] Zip-bomb guard in src/extract/zip.ts (and pdf.ts inflate) trusts the declared uncompressedSize, so a member that lies still inflates unbounded via DecompressionStream — comment's 'refused rather than expanded' guarantee overstates the actual protection --- When addressing the review on #185, resolve each item and add `Closes #` to the PR once everything is genuinely [Read the thread](https://github.com/chrischall/ofw-mcp/issues/186) · 2026-07-27 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #179: fix: stop ofw_save_draft self-inflicting STALE_DRAFT and silently dropping replyToId Tracking auto-review follow-ups for #179 (verdict: **warn**). ### 🟡 Nits - [ ] Dropped-replyToId warning in src/tools/messages.ts:754-756 claims 'inReplyTo/showContext will be empty ... only the reply linkage was dropped' even on the re-target-to-non-null branch, contradicting the non-null inReplyTo the same response echoes --- When addressing the review on #179, resolve each item and add `Closes #` to the PR once everything is genuinely fixed; [Read the thread](https://github.com/chrischall/ofw-mcp/issues/180) · 2026-07-26 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #148: fix: reconcile cached read flag with recipient viewedAt Tracking auto-review follow-ups for #148 (verdict: **warn**). ### 🟡 Nits - [ ] selfUserId is never passed to withReadState/deriveRead by any call site in src/tools/messages.ts, so the id-matched inbox branch documented as primary is unreachable in production and only the '1:1 messaging' any-recipient fallback ever runs --- When addressing the review on #148, resolve each item and add `Closes #` to the PR once everything is genuinely fixed; defe [Read the thread](https://github.com/chrischall/ofw-mcp/issues/149) · 2026-07-18 · closed · outside contributor · 0 comments ### Proposal: runtime validation of OFW API responses at the client boundary Every `client.request(...)` is a blind cast (`JSON.parse(text) as T`) of a reverse-engineered, undocumented API. The test suite's 100% coverage is real, but every test mocks `OFWClient.request` with the same hand-written shapes — so the suite proves the code is consistent with the *assumed* API, never with the real one. When OFW ships a backend change (renames `entityId`, restructures `date`, changes `showNeverViewed` semantics), nothing fails loudly. Instead `undefined` flows into the SQLit [Read the thread](https://github.com/chrischall/ofw-mcp/issues/83) · 2026-06-10 · closed · outside contributor · 0 comments ### Proposal: OFW_WRITE_MODE gate (none/drafts/all) for structural write protection The README's tool table describes write tools as \"Confirm\" — but MCP annotations (`destructiveHint` etc.) are host *hints*, not enforcement. A host configured with auto-approve (or a user who clicked \"always allow\" once) leaves zero barrier between model output and a sent message. Given OFW is a court-of-record platform, and given that synced inbox messages are untrusted co-parent-authored text flowing into the model's context (a textbook prompt-injection vector), a server-side gate seems wo [Read the thread](https://github.com/chrischall/ofw-mcp/issues/82) · 2026-06-10 · closed · outside contributor · 1 comment ## Most recent ### Auto-review follow-ups for PR #229: feat: lead paginated list responses with paging state, add nextPage and sort Tracking auto-review follow-ups for #229 (verdict: **warn**). ### 🟡 Nits - [x] readUpstreamPaging (src/tools/pagination.ts:130-139) counts only rows under `data`, so a non-`data` envelope publishes `returned: 0` and a 'reaches the end of the list' note next to real records — and reports hasMore:false on a full page (tests/tools/journal.test.ts:31-45 exhibits it) - [x] withPaginationFirst (src/tools/pagination.ts:189-201) spreads the upstream body after the [Read the thread](https://github.com/chrischall/ofw-mcp/issues/230) · 2026-08-23 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #218: refactor(connector): retire the standalone Cloudflare Worker connector Tracking auto-review follow-ups for #218 (verdict: **warn**). ### 🟡 Nits - [ ] vitest.config.ts:16-25 — two comments still cut mid-sentence by the connector deletion; line 16-17 has no object for "the only visible symptom is the copied", and lines 24-25 are a dangling comment above `],` starting mid-sentence with "root-anchored" - [ ] src/cache/store.ts:7 — the header still calls the Durable-Object cache backend "(a later task)", a forward reference to work [Read the thread](https://github.com/chrischall/ofw-mcp/issues/219) · 2026-08-07 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #206: feat(messages): guarded send-by-draft, accurate threading verdicts, lifecycle fixes Tracking auto-review follow-ups for #206 (verdict: **warn**). ### 🟡 Nits - [x] src/tools/messages.ts:707 — `echoReported` treats a present-but-null `replyToId` as positive evidence of a dropped reply link, the exact shape OFW uses for threaded items; a `{replyToId: null}`-only sent detail yields a false UNTHREADED warning and caches `replyToId`/`chainRootId` as null, dropping the message out of `findLatestReplyTip` - [x] src/tools/messages.ts:1185 — `ofw_sa [Read the thread](https://github.com/chrischall/ofw-mcp/issues/207) · 2026-07-31 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #200: fix: emit every timestamp with an explicit offset and a display value Tracking auto-review follow-ups for #200 (verdict: **warn**). ### 🟡 Nits - [ ] src/timestamps.ts wallTimeToInstant lands a non-existent spring-forward wall time (2026-03-08T02:30 ET) one hour BACKWARD at 01:30-05:00 while the comment claims it shifts forward; tests/timestamps.test.ts:99 only asserts the date prefix so the mismatch is invisible - [ ] src/timestamps.ts isValidTimeZone builds an uncached Intl.DateTimeFormat on every displayTimeZone() call, i.e [Read the thread](https://github.com/chrischall/ofw-mcp/issues/201) · 2026-07-28 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #196: feat(messages): make it impossible to report stale draft/message state Tracking auto-review follow-ups for #196 (verdict: **warn**). ### 🟡 Nits - [x] src/tools/draft-freshness.ts:71 — new `folder.id` field is asserted `z.number()` on a `mode: 'strict'` schema that the destructive-draft guard depends on; OFW's folders-listing endpoint returns folder ids as strings, so accept `z.union([z.string(), z.number()])` to avoid a type surprise hard-failing ofw_save_draft/ofw_delete_draft - [x] src/tools/messages.ts (ofw_check_freshness) [Read the thread](https://github.com/chrischall/ofw-mcp/issues/197) · 2026-07-28 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #190: fix: correct three misleading messages and skip an empty cache RPC Tracking auto-review follow-ups for #190 (verdict: **warn**). ### 🟡 Nits - [ ] src/tools/draft-freshness.ts:77-79 — fetchServerDraft's docstring still says failures throw only DraftFreshnessError, the same overstatement issue #159 just fixed at the messages.ts call site (strict parseLenient can throw McpToolError instead) --- When addressing the review on #190, resolve each item and add `Closes #` to the PR once everything is genuinely fixed; d [Read the thread](https://github.com/chrischall/ofw-mcp/issues/191) · 2026-07-27 · closed · outside contributor · 0 comments ### Auto-review follow-ups for PR #158: fix: refuse to overwrite a draft that changed on OFW since it was cached Tracking auto-review follow-ups for #158 (verdict: **pass**). ### 🟡 Nits - [ ] guardDestructiveDraftOp catch-block comment (messages.ts:464) overstates that fetchServerDraft funnels every non-404 failure into DraftFreshnessError — a strict parseLenient mismatch throws McpToolError instead (still caught/aborts correctly) --- When addressing the review on #158, resolve each item and add `Closes #` to the PR once everything is genuinely fixed; def [Read the thread](https://github.com/chrischall/ofw-mcp/issues/159) · 2026-07-19 · closed · outside contributor · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/chrischall/ofw-mcp/issues).