feat(mcp): let local agents handle approved removal follow-ups

[magnus188]

Pending removal requests often lead to forms and confirmation links that users still have to handle by hand. This adds eraser mcp, a local connection that lets Codex work through those follow-ups after the user reviews and approves a specific batch.

How it works

1. The agent reads pending tasks and prepares a preview showing the profile, destinations, and any email drafts.
2. The user approves that batch. The agent can then fill forms, open confirmation links, or send the reviewed emails.
3. Receipts, screenshots, and items needing help appear in Eraser's existing Tasks page.

For example, a form showing “Your request has been received” completes the follow-up task. A CAPTCHA pauses for the user, and a rejected or uncertain submission stays open for review. An accepted request does not mean the broker has erased the data.

What is included

• A local MCP server using the official Go SDK, with tools for tasks, batch approval, forms, confirmation links, inbox scanning, and reviewed email requests.
• Reuse of existing profiles, email settings, templates, exclusions, sending limits, and history.
• An action journal that records attempts before submission and prevents automatic retries when the outcome is uncertain.
• Task-page improvements for saved screenshots, completed-task evidence, and items needing review.
• A fictional local demo, setup instructions, and example Codex configuration.

Limits to keep in mind

The MCP client must prompt for begin_batch and retry_action; the example configuration includes those settings. The server enforces the approved profile, tasks, and destinations.

Form automation uses Chrome/Chromium. CAPTCHA, login, identity checks, and unexpected destinations require human intervention. Embedded forms and third-party dependencies may also need manual handling.

Validation

• Build, go vet ./..., go test -race ./..., formatting, and golangci-lint run passed.
• Broker validation passed for all 724 entries.
• Browser tests ran with an explicit Chrome executable, including the MCP demo workflow.
• Manually tested the approval flow in eraser_demo: access was blocked before approval; the simple form, multiple-step form, and confirmation link completed; human verification paused; the rejected request remained unresolved without a retry. The saved results matched the Tasks page viewed in the Codex browser.

The manual demo used fictional data and did not contact real brokers or send real email.

[JustMaris]

Thanks. The prepare -> approve -> begin flow, config digest check and action journal are well thought out. Not merging for now. Main concerns:

1. Approval can't be verified by the server. begin_batch is only gated by the MCP client's prompt, so an auto-approving client (or a prompt-injected page/email) can start a batch. Please move approval out of band: prepare_batch stores the preview and digest in history.db, the localhost web UI shows it with an Approve button (CSRF-protected), and begin_batch only succeeds with a single-use, expiring approval for that digest. This doesn't stop a malicious local agent running as the user, but it does stop prompt injection.
2. Human vs MCP attribution. Please record an actor (human/mcp, plus client name) on journal entries, completed tasks and request/pipeline updates, and show it on the Tasks page and in export, instead of the free-text "MCP:" note prefix.
3. Domain scope. BrokerDomains allows all subdomains of the broker's website and opt_out_url hosts. About 44 entries in data/brokers.yaml point at shared portal/form platforms, so a whole platform (and any tenant on it) becomes an allowed destination for profile data. Please allow the exact host for those, with subdomains opt-in.
4. DNS check is TOCTOU. URLPolicy.Validate resolves in Go but Chrome resolves separately. Consider also checking the remote IP Chrome reports.
5. Pipeline status can go backwards. UpdatePipelineStatus(..., AwaitingResponse) after a form accept would overwrite confirmed (and, after #158, the no-data status). Only advance from earlier stages.
6. Receipt detection trusts agent-quoted text from an untrusted page plus an English regex. Worth documenting as a known limit.
7. Dependencies/CLI surface. The MCP SDK adds several indirect modules, and eraser mcp joins the 1.x CLI contract in docs/stability.md. Is that intended, or should it be marked experimental?
8. Docs. The learn.chatgpt.com/docs/extend/mcp link looks wrong; please verify. Add docs/mcp.md to the Docs Map in CLAUDE.md. Please confirm CI installs Chrome so the browser tests aren't silently skipped.

Also expect a rebase after #158 (overlap in history.go, inbox/scan.go, web/handlers_pages.go).