[jwalin-shah]

Purpose

Prove the smallest useful ChatGPT Business -> LifeOps MCP -> Inbox/Mac vertical slice without exposing the full Inbox REST API or weakening existing approval invariants.

Adds

• lifeops_mcp.py: tool-only FastMCP adapter
• scripts/run_lifeops_mcp_v0.sh: local Inbox + MCP launcher
• docs/lifeops-mcp-v0.md: Secure MCP Tunnel / ngrok dev guidance and acceptance test

V0 tools

Read:

• search / fetch
• source health
• calendar events
• travel/departure times
• Google Tasks

Bounded writes:

• propose Google Task creation
• propose Calendar event update
• explicit approval
• exact lease-bound execution

The adapter allowlists only task creation and calendar updates for approval/execution. It does not expose arbitrary REST, shell/filesystem, messaging writes, or deletes.

First acceptance test

Use the existing Street play practice case to prove:
message evidence -> calendar correlation -> travel calculation -> proposed event enrichment -> explicit approval -> execution -> read-back verification -> departure time.

Validation so far

• Python syntax compile passed for lifeops_mcp.py in an isolated container.
• Current MCP SDK docs/source were checked for ToolAnnotations snake_case names.
• Branch is 3 commits ahead of main, 0 behind.
• Host/runtime integration has not yet been exercised on the Mac because this environment does not have the repo's mcp dependency or access to the local Inbox data stores.

Keep draft until the Mac runtime + ChatGPT Developer Mode acceptance test passes.

[jwalin-shah]

PEV-AUT-BPB-20260903T0325-INBOX-GOOGLE-REHYDRATE

Material runtime blocker found (2026-09-03): the LifeOps/Inbox control plane is reachable, but every Google provider currently reports configured=true, authenticated=true, and readable=false/syncable=false/writable=false with the same blocker: oauth_token_present_but_service_not_loaded. All three configured Google accounts have token diagnostics, while the active server has zero loaded Gmail/Calendar/Drive/Sheets/Docs/Tasks service objects. Historical capture probes show those services last worked on 2026-09-01, so this is a service-hydration/runtime problem first, not evidence that all OAuth grants are gone.

This directly blocks this PR's v0 acceptance test (source_health, Calendar, Tasks) and also blocks the higher-level project/task/Drive/Sheets read surfaces that depend on Inbox.

Current repo anchors:

• main: be61619275150bbb0a608dfb62021bc2859488d0
• PR LifeOps MCP v0: bounded ChatGPT Business cockpit over Inbox #67 head: 4509e86cc7c8ae19a93907b074573fed40f9c217
• diagnostic helper: scripts/restore_google_oauth.sh
• v0 launcher: scripts/run_lifeops_mcp_v0.sh

Code inspection narrows the recovery path. inbox_server.py calls google_auth_all() during FastAPI lifespan startup and assigns the six returned service maps into state.*_services; /accounts/add and /accounts/reauth also rerun google_auth_all() and reassign the same maps. services.google_auth_all() loads each tokens/*.json, refreshes it if needed, then builds Gmail/Calendar/Drive/Sheets/Docs/Tasks clients independently. Therefore do not start with blanket OAuth re-consent.

Executor sequence (local Mac only; no write actions to Gmail/Calendar/Tasks are required):

cd ~/projects/inbox
git fetch origin
git switch main
git reset --hard be61619275150bbb0a608dfb62021bc2859488d0

# 1. Read-only diagnosis. This checks /health and
# /accounts/auth-status?check_refresh=true.
# It requires INBOX_SERVER_TOKEN (or ~/.config/inbox/server.env) and
# credentials.json, but does not start OAuth unless --start is supplied.
./scripts/restore_google_oauth.sh | tee /tmp/inbox-google-auth-before.txt

# 2. If every token is already_valid or refresh_status=ok with no
# missing_required_scopes, restart/rehydrate the Inbox server first.
# A clean startup must invoke google_auth_all() automatically.
# Use the machine's existing service supervisor if one owns :9849;
# otherwise for the PR-67 acceptance harness:
git switch lifeops-mcp-v0
export INBOX_SERVER_TOKEN="$(grep '^INBOX_SERVER_TOKEN=' "$HOME/.config/inbox/server.env" | cut -d= -f2-)"
bash scripts/run_lifeops_mcp_v0.sh

# 3. Read back provider state from a second shell.
curl -fsS -H "Authorization: Bearer ${INBOX_SERVER_TOKEN}" \
  http://127.0.0.1:9849/status/providers | python3 -m json.tool
curl -fsS -H "Authorization: Bearer ${INBOX_SERVER_TOKEN}" \
  http://127.0.0.1:9849/capture/health | python3 -m json.tool

# 4. Only if auth-status shows a specific account with refresh_status=failed,
# unreadable_token, missing_required_scopes, or revoked refresh credentials,
# re-auth that account explicitly rather than re-consenting all accounts:
curl -fsS -X POST \
  -H "Authorization: Bearer ${INBOX_SERVER_TOKEN}" \
  -H 'Content-Type: application/json' \
  -d '{"email":"<affected-account>"}' \
  http://127.0.0.1:9849/accounts/reauth | python3 -m json.tool

Acceptance: all expected Google provider rows lose oauth_token_present_but_service_not_loaded; Gmail/Calendar/Drive/Sheets/Docs/Tasks have loaded account service maps and are readable=true; no refresh failures/missing scopes remain for the configured accounts; fresh capture probes succeed; PR #67's source_health() then reports usable Calendar/Tasks before any propose/approve/execute test begins. Preserve INBOX_SERVER_ALLOW_UNAUTHENTICATED as false and do not log token contents.

Kill/escalate: stop before OAuth mutation if the dry run shows all tokens valid yet a clean server startup still produces empty service maps—capture the google_auth_all.*_service startup errors instead, because that indicates client-build/environment failure rather than OAuth. Also stop if recovery requires deleting tokens/, replacing credentials.json from an untrusted source, enabling auth bypass, or widening any approval/write policy. If only one account is bad, do not re-auth the other two.

This packet is executor-ready; no local process, OAuth browser flow, Work/Codex run, or scarce inference was launched here.

[jwalin-shah]

Triage 2026-09-06: superseded by Inbox MCP control-plane :8002 (PR #71/#77).