Feature: bm feedback CLI command + cloud endpoint

[bm-clawd]

Feature: bm feedback CLI command

Inspired by actors.dev adding a /feedback endpoint and an agent actually using it.

CLI

bm feedback "search is slow on large projects"
bm feedback "temporal queries return wrong results" --include-context
bm feedback "love the new schema tools" --email user@example.com

Payload

{
  "message": "search is slow on large projects",
  "instanceId": "generated-unique-install-id",
  "version": "0.19.0",
  "os": "Darwin 23.6.0",
  "python": "3.13.1",
  "noteCount": 342,
  "email": null
}

• --include-context: opt-in, attaches project stats (entity count, note count)
• --email: optional, for follow-up

Cloud endpoint

POST cloud.basicmemory.com/api/feedback

• No auth required (instance ID used for rate limiting)
• Rate limit: 10/day per instanceId, 3/day per IP without instanceId
• Instance ID generated on first bm run, stored locally

Anti-spam

• Instance ID + rate limiting per ID and IP
• Lightweight — no GitHub auth, no cloud account required
• Works for both OSS and cloud users

On our end (triage)

• Store in DB
• Webhook to Discord #feedback channel
• Triage manually, create GH issues for actionable bugs

MCP tool

Also expose as an MCP tool so agents using BM can submit feedback programmatically. This is the actors.dev moment — agents as first-class API consumers giving us bug reports.

Why not GitHub issues directly?

• Requires GitHub auth (high friction)
• Clutters issue tracker
• We lose triage control

Why not email?

• More friction than CLI
• Harder to aggregate/search

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[phernandez]

Implementation Plan

Detailed design from planning session — ready to pick up in a post-v0.19.0 point release.

Architecture

Two user paths, one tool:

• Local/OSS users — no account, no auth. Instance ID in payload, rate limiting on cloud side.
• Cloud users — already authenticated via JWT/API key. Bearer token attached automatically.

The feedback tool stays dumb — it collects message + context, hands off to the existing client routing. Auth is injected at client creation, not per-request.

basic-memory repo (client side)

File	Action	Purpose
src/basic_memory/schemas/feedback.py	NEW	FeedbackRequest / FeedbackResponse Pydantic models
src/basic_memory/feedback.py	NEW	Shared build_feedback_request() + send_feedback() — used by both CLI and MCP
src/basic_memory/mcp/tools/feedback.py	NEW	MCP tool: feedback(message, email?, include_context?)
src/basic_memory/cli/commands/feedback.py	NEW	CLI: bm feedback "msg" [--email] [--include-context]
src/basic_memory/config.py	MODIFY	Add instance_id field, auto-generate UUID4 on first run, persist via needs_resave
src/basic_memory/mcp/async_client.py	MODIFY	Add get_feedback_client() — like get_cloud_control_plane_client() but doesn't raise on missing credentials
src/basic_memory/mcp/tools/__init__.py	MODIFY	Register feedback tool
src/basic_memory/cli/commands/__init__.py	MODIFY	Register feedback command
src/basic_memory/cli/app.py	MODIFY	Add "feedback" to skip_init_commands

Key pattern — get_feedback_client():

@asynccontextmanager
async def get_feedback_client() -> AsyncIterator[AsyncClient]:
    config = ConfigManager().config
    headers = {}
    try:
        token = await _resolve_cloud_token(config)
        headers["Authorization"] = f"Bearer {token}"
    except RuntimeError:
        pass  # OSS user — send unauthenticated
    async with AsyncClient(base_url=config.cloud_host, headers=headers) as client:
        yield client

Payload:

{
  "message": "search is slow on large projects",
  "instance_id": "generated-uuid4",
  "version": "0.19.0",
  "os_info": "Darwin 25.3.0",
  "python_version": "3.13.1",
  "note_count": 342,
  "email": null
}

basic-memory-cloud repo (server side)

File	Action	Purpose
api/feedback.py	NEW	POST /api/feedback — accepts both Bearer-authenticated and unauthenticated requests
models/feedback.py	NEW	SQLAlchemy model: id, message, instance_id, user_profile_id (nullable), version, os_info, python_version, note_count, email, ip_address, created_at
repositories/feedback_repository.py	NEW	CRUD + rate-limit queries (recent by instance_id, recent by IP)
main.py	MODIFY	Register as unauthenticated router (like public_note_router)

Auth strategy on cloud side:

• Check for Bearer token first → validate JWT → extract user_id (trusted, known user)
• No Bearer → accept with instance_id, rate limit by instance_id + IP
• Rate limits: 10/day per instance_id, 3/day per IP without instance_id
• Can add HMAC signing later if spam becomes a problem

Anti-spam (deferred)

MVP: rate limiting only. No HMAC, no proof-of-work. Instance ID provides cohort tracking, IP rate limiting prevents abuse. If spam becomes an issue, options:

1. Instance registration + HMAC (first POST registers secret, subsequent requests signed)
2. Hash-based proof of work
3. Simple captcha-like challenge

Tests needed

• Schema validation (required/optional fields)
• build_feedback_request populates system info correctly
• send_feedback with/without auth headers
• MCP tool success/error/include_context paths
• CLI via typer runner: success output, flags, error handling
• Config instance_id auto-generation and persistence

Discord webhook (future follow-up)

Store to DB first. Add webhook to Discord #feedback channel in a separate PR. Structured embed with payload fields for easy scanning.