diff --git a/foundry/CLAUDE.md b/foundry/CLAUDE.md
index dc14906..83e94e3 100644
--- a/foundry/CLAUDE.md
+++ b/foundry/CLAUDE.md
@@ -203,6 +203,7 @@ For all Rivet/RivetKit implementation:
   - For Foundry live verification, use `rivet-dev/sandbox-agent-testing` as the default testing repo unless the task explicitly says otherwise.
   - Secrets (e.g. `OPENAI_API_KEY`, `GITHUB_TOKEN`/`GH_TOKEN`) must be provided via environment variables, never hardcoded in the repo.
   - `~/misc/env.txt` and `~/misc/the-foundry.env` contain the expected local OpenAI + GitHub OAuth/App config for dev.
+  - Local GitHub webhook forwarding uses Smee. Set `SMEE_URL` and `SMEE_TARGET` in those env files; `compose.dev.yaml` runs a `smee` service that forwards to `http://backend:7741/api/rivet/app/webhooks/github`.
   - Do not assume `gh auth token` is sufficient for Foundry task provisioning against private repos. Sandbox/bootstrap git clone, push, and PR flows require a repo-capable `GITHUB_TOKEN`/`GH_TOKEN` in the backend container.
   - If browser GitHub OAuth suddenly fails with symptoms like `GitHub OAuth is not configured` while other GitHub flows seem to work, first check whether the backend is relying on a `GITHUB_TOKEN` override instead of the OAuth/App env from `~/misc/env.txt` and `~/misc/the-foundry.env`. In local dev, clear `GITHUB_TOKEN`/`GH_TOKEN`, source those env files, and recreate the backend container; `docker restart` is not enough.
   - Preferred product behavior for org workspaces is to mint a GitHub App installation token from the workspace installation and inject it into backend/sandbox git operations. Do not rely on an operator's ambient CLI auth as the long-term solution.
diff --git a/foundry/compose.dev.yaml b/foundry/compose.dev.yaml
index 3a17e7d..95a55f1 100644
--- a/foundry/compose.dev.yaml
+++ b/foundry/compose.dev.yaml
@@ -111,6 +111,24 @@ services:
       - "foundry_shared_node_modules:/app/foundry/packages/shared/node_modules"
       - "foundry_pnpm_store:/tmp/.local/share/pnpm/store"
 
+  smee:
+    image: node:20-alpine
+    depends_on:
+      - backend
+    environment:
+      SMEE_URL: "${SMEE_URL:-}"
+      SMEE_TARGET: "${SMEE_TARGET:-http://backend:7741/api/rivet/app/webhooks/github}"
+    command:
+      - /bin/sh
+      - -lc
+      - |
+        if [ -z "$SMEE_URL" ]; then
+          echo "SMEE_URL is not set; exiting"
+          exit 1
+        fi
+        npx --yes smee-client --url "$SMEE_URL" --target "$SMEE_TARGET"
+    restart: unless-stopped
+
 volumes:
   foundry_backend_root_node_modules: {}
   foundry_backend_backend_node_modules: {}
diff --git a/foundry/packages/backend/CLAUDE.md b/foundry/packages/backend/CLAUDE.md
index cb21c4f..2aee155 100644
--- a/foundry/packages/backend/CLAUDE.md
+++ b/foundry/packages/backend/CLAUDE.md
@@ -50,6 +50,7 @@ AppShellOrganization("app")
 ## Daytona Provider Rules
 
 - Daytona sandbox lifecycle uses native Daytona control-plane operations only: create, get, start, stop, delete, and preview endpoint lookup.
+- Local GitHub webhook forwarding in dev uses Smee. `compose.dev.yaml` runs a `smee` service; set `SMEE_URL` and `SMEE_TARGET` in `~/misc/env.txt` / `~/misc/the-foundry.env` so webhook traffic relays into `http://backend:7741/api/rivet/app/webhooks/github`.
 - Once a Daytona sandbox exists, the backend must treat sandbox-agent as the runtime surface. Run in-sandbox commands through sandbox-agent process APIs, not Daytona native process execution.
 - The Daytona snapshot image must fail fast if `sandbox-agent` or agent installation fails. Do not hide install failures with `|| true`.
 - Daytona does not reliably replace PID 1 with the image `ENTRYPOINT`/`CMD`. Start `sandbox-agent server` after sandbox creation via Daytona's native process API, then use sandbox-agent for all normal runtime commands.