Error Log

Append-only record of MCP failures and their fixes, per the Self-Correction Loop in CLAUDE.md.

2026-07-01 — Notion MCP tools not discoverable despite “Connected” status

What went wrong: claude mcp list reports claude.ai Notion as ✔ Connected, but ToolSearch returns zero Notion tools (tried notion, +notion, notion create pages database, notion_create_pages, exact select:mcp__claude_ai_Notion__... names) — both in the session where the connector was first authorized AND after a full Claude Code restart.
Attempted fix that did NOT work: Restarting the Claude Code session (this is the normal fix for “MCP connected mid-session, tools not loaded yet” — did not resolve it here).
Status: UNRESOLVED after 2 full Claude Code restarts AND a full disconnect/reconnect of the Notion connector at claude.ai → Settings → Connectors (user confirmed page/workspace access granted on reconnect). claude mcp list consistently reports claude.ai Notion: ✔ Connected throughout, but ToolSearch never surfaces a single Notion tool.
Conclusion: NOT Notion-specific. Confirmed 2026-07-01 that Gmail also shows ✔ Connected in claude mcp list but exposes zero tools via ToolSearch (tried “gmail search messages list”). All three claude.ai connectors (Gmail, Google Calendar, Notion) are affected identically — reports healthy, zero tools. This points to a systemic issue in this environment/harness’s connector-tool wiring, not a per-connector auth problem. Proceeding with local-only tracking. Recommend reporting to Anthropic support with this log as reference rather than continuing to retry restarts/reconnects.

Resolved 2026-07-01 (later same day): Re-checked in a fresh session — ToolSearch surfaced Gmail, Calendar, and Notion tools normally, and all three responded (Gmail list_labels/search_threads, Calendar list_events, Notion search/create-database/create-pages). No action taken beyond a fresh session; whatever the harness-side wiring issue was, it cleared on its own. Ran the Notion Bootstrap Protocol: created the “Personal OS” parent page and the “Progress Tracker” database under it — see notion-parent-id and status.

2026-07-01 — notion-query-data-sources (SQL and view mode) requires Notion Business plan

What went wrong: Building Sprint Tracker, tried to read the Progress Tracker board with notion-query-data-sources in both sql and view mode. Both returned validation_error: “This tool requires a Business plan or higher with Notion AI.”
Fix: Don’t use notion-query-data-sources on this workspace. Instead, notion-fetch each page directly by ID (IDs are known from notion-create-pages responses, or from prior fetches) — this reads <properties> including Status/Order/Notes with no plan gate. For boards with unknown page IDs, notion-search scoped with data_source_url is the fallback, though it returned empty results even for known content on 2026-07-01 (may be an indexing lag, not yet confirmed reliable).
Status: RESOLVED — use per-page notion-fetch, not the query tool, for any workspace on a sub-Business plan.

2026-07-03 — Notion MCP tools not discoverable again (same as 2026-07-01 pattern)

What went wrong: Running /market-pulse, ToolSearch for Notion tools (notion, create pages database search fetch workspace) returned zero results — same symptom as the 2026-07-01 incident, which resolved itself in a fresh session.
Fix: Did not restart session mid-run (would lose scan state). Proceeded with local-only tracking per the Bootstrap Protocol fallback (“If Notion MCP is unavailable, write deliverables locally and skip the DB step”). No new Market Scans row created this run — needs a manual backfill next time Notion tools are confirmed working, or the next run will just add a fresh row and this gap goes unfilled.
Status: UNRESOLVED for this session. Try a fresh session next scheduled run before assuming it’s broken again.

2026-07-03 — Gmail/Calendar/Notion all undiscoverable again, /morning-brief

What went wrong: Running /morning-brief, ToolSearch for Gmail (gmail, select:mcp__gmail_search_threads,mcp__gcal_list_events), Calendar (calendar events), and Notion (notion search) all returned zero tools. Third occurrence of this exact pattern (2026-07-01 twice, now 2026-07-03), always self-resolving in a fresh session, never fixed by in-session retry.
Fix: Did not burn a session restart mid-run. Produced the brief from vault-only context (soul.md, goals, existing people/business pages, prior brief history) and flagged the gap explicitly instead of fabricating email/calendar/Notion data. Skipped the Notion “Daily Briefs” row per the bootstrap fallback (“if Notion MCP is unavailable, write deliverables locally and skip the DB step”).
Status: UNRESOLVED for this session. Pattern is frequent enough (3 occurrences in 3 days) to be worth flagging to Anthropic support directly rather than treating as one-off. Next scheduled run should try fresh — do not assume connectors are permanently broken.

2026-07-03 — Gmail/Notion undiscoverable again, /email-triage (4th occurrence)

What went wrong: Running /email-triage interactively, ToolSearch for Gmail (gmail, mail) and Notion (notion) returned zero tools, same session as the /morning-brief failure logged above (same day, same pattern, connectors never came back mid-session).
Fix: Did not restart mid-run. Email-triage’s core function (reading the inbox) is impossible without Gmail — unlike morning-brief, there’s no meaningful vault-only fallback for classifying threads that don’t exist yet in the vault. Halted before drafting or writing fabricated data. Flagged to Suraj directly, no Notion rows or run file written.
Status: UNRESOLVED for this session. 4 occurrences across 3 days (2026-07-01 x2, 2026-07-03 x2), always self-resolving in a fresh session only. Worth flagging to Anthropic support with this log. Next attempt: fresh session.

2026-07-03 — Notion undiscoverable again, /sprint-tracker (5th occurrence)

What went wrong: Running /sprint-tracker, ToolSearch for notion search fetch create pages database and a direct select:notion-fetch,notion-query-data-sources,notion-search,notion-create-pages both returned zero tools. Same session as the /morning-brief and /email-triage failures above — connectors never recovered mid-session.
Fix: Wrote the standup from the last verified board state in status.md (checked 2026-07-02) instead of re-querying. No new Notion standup page created, no Notion write attempted — skipped per bootstrap fallback.
Status: UNRESOLVED. 5 occurrences across 3 days, 3 of them today alone (morning-brief, email-triage, sprint-tracker). This is no longer “occasional flakiness” — every automation this session that touches a claude.ai connector has hit it. Strongly worth flagging to Anthropic support with this full log rather than continuing to retry per-run. Next scheduled run: try a fresh session before assuming permanently broken.

2026-07-03 — Root-cause diagnosis + fix for the recurring MCP outage (morning-brief, email-triage, sprint-tracker)

Evidence gathered, not guessed:

• Task Scheduler history (schtasks /query /v) confirms PersonalOS-email-triage and PersonalOS-sprint-tracker both fired at 9:00:00-9:00:01 AM on 2026-07-03, the same minute — directly contradicting this log’s earlier claim (5th-occurrence entry above) that email-triage ran “interactively.” It was cron-spawned, concurrent with sprint-tracker. This was a real, previously undocumented scheduling collision.
• PersonalOS-morning-brief fired solo at 8:00:01 AM with no overlapping job, and also failed — so the 9 AM collision cannot be the sole cause.
• Live diagnostic: ran claude -p twice in a row, same headless invocation + persistent CLAUDE_CODE_OAUTH_TOKEN env-var auth the cron jobs use, asking it to call ToolSearch for gmail/calendar/notion tools. Both attempts succeeded (7 tools resolved each time), ruling out “headless env-token mode structurally cannot reach connectors” (hypothesis b, session/auth carryover). Could not force a live repro of this morning’s actual failure window.
• Conclusion: best-supported mechanism is hypothesis (a), a transient/racy delay in MCP tool registration at session startup — consistent with the historical pattern (always self-clears in a fresh session, first-call failure not an auth error, not reproducible on demand). Confidence is moderate, not absolute — genuinely can’t rule out a transient upstream connector-service issue specific to that morning’s time window, which is outside what this repo can observe. The 9 AM scheduling collision is a real, independently-worth-fixing contributing factor even though it doesn’t explain the 8 AM solo failure.
  Fix implemented:

1. Added a mandatory “Step 0.5: MCP connector check” to .claude/commands/morning-brief.md, email-triage.md, sprint-tracker.md — calls ToolSearch for the connector tools that automation needs; if zero resolve, retries after sleep 5 (attempt 2) then sleep 10 (attempt 3); logs which attempt succeeded or that all 3 failed to this file in a standard format, before falling back to each automation’s existing degraded mode. This lives in the command instructions, not the PowerShell wrapper, since only a running Claude session can call ToolSearch.
2. Rescheduled PersonalOS-sprint-tracker from 9:00 AM to 8:55 AM (weekdays) to eliminate the exact-same-minute collision with Email Triage’s 9:00 AM slot. See scheduler/schedule.md.
   Status: Fix implemented, not yet proven — the retry mechanism logs its own outcome each run specifically so we can measure whether occurrences actually drop, rather than assume the fix worked. Check this file after a few days of scheduled runs: if “RESOLVED (attempt 2/3)” entries start appearing where full 3x failures used to happen, the retry is doing real work. If “DEGRADED (all 3 failed)” keeps appearing at the same rate, the delay is longer than 15 seconds total and the backoff windows need widening — escalate to Anthropic support with this full log either way, the underlying registration delay isn’t something this repo can fix directly.