chore: Bake cursor-dev-setup Cloud Agent image

[PrashamTrivedi]

Summary

• Cloud Agents now FROM ghcr.io/prashamtrivedi/cursor-dev-setup:v1.0.0 so skills/commands from CursorPlugin are on the VM.
• install runs materialize-cursor-harness.sh first; app install/start stay the same.

Test plan

• Confirm GHCR image ghcr.io/prashamtrivedi/cursor-dev-setup:v1.0.0 is public/pullable
• Trigger a Cloud Agent environment rebuild after merge
• Agent can see harness skills/commands under ~/.cursor

[github-actions]

🤖 Hi @PrashamTrivedi, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	memory-server	c6fcfb9	Commit Preview URL Branch Preview URL	Sep 04 2026, 09:29 AM

[github-actions]

🤖 I'm sorry @PrashamTrivedi, but I was unable to process your request. Please see the logs for more details.

[claude]

Review: chore: Bake cursor-dev-setup Cloud Agent image

Nice direction — moving from a curl -fsSL https://bun.sh/install | bash bootstrap to a pinned base image is a genuine improvement for both reproducibility and supply-chain hygiene, and it makes install far cheaper on every rebuild.

The PR body describes this as "app install/start stay the same," but the diff actually drops four things from environment.json beyond the bun bootstrap. Two of them look like unintended regressions.

---

🔴 Local D1 migrations are no longer applied on start

Before:

"start": "... bunx wrangler d1 migrations apply memory-db --local && bun run dev"

After:

"start": "bun run dev"

wrangler.jsonc binds DB to memory-db, and migrations/ has four files (0001_tag-hierarchy → 0004_skill_keys). A Cloud Agent VM starts with an empty .wrangler/ state dir, so the local D1 instance now comes up with no tables at all. The first request that touches memories, tags, or API keys will fail with D1_ERROR: no such table, and the agent gets an opaque runtime error rather than a clear setup failure.

Unless the base image applies migrations itself, I'd restore this:

"start": "bunx wrangler d1 migrations apply memory-db --local && bun run dev"

(The export PATH prefix is correctly no longer needed if bun is on PATH in the image.)

🔴 ui/ dependencies are no longer installed

Before: ... && bun install && (cd ui && (npm ci || npm install) || true)
After: ... && bun install

ui/ is a separate package (memory-server-ui) with its own package.json and package-lock.json, and the root package.json declares no workspaces field — so root bun install will not reach it. Any agent asked to touch the UI now hits a cold node_modules and has to figure out the install step itself.

The old form was || true-guarded, so restoring it is low-risk:

"install": "/opt/prasham-cursor/bin/materialize-cursor-harness.sh && bun install && (cd ui && (npm ci || npm install) || true)"

---

🟡 ports declaration dropped

The old config declared {"name": "worker", "port": 8787}. If that was load-bearing for previewing the worker from the Cursor UI, it should come back — the switch to a build block doesn't replace it. If it was purely decorative because Cursor auto-detects listening ports, ignore this.

🟡 Secrets documentation lost

The old file carried a genuinely useful comment:

// Secrets cannot live in this file — add names below in the Cursor dashboard Secrets tab.
// CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN, DATABASE_ID, KV_NAMESPACE_ID, EMAIL_API_KEY, NOTIFICATION_EMAIL

That's the only place in the repo naming what has to be configured in the Cursor dashboard (.env.sample covers app env, not this). Since the file is already JSONC, it costs nothing to keep — worth re-adding.

---

🟡 && chaining makes a harness failure fatal to the whole install

"install": "/opt/prasham-cursor/bin/materialize-cursor-harness.sh && bun install"

Two things here:

1. Hard-coded absolute path into an external image. /opt/prasham-cursor/bin/... couples this repo to the internal layout of cursor-dev-setup. If that image reorganizes, this breaks with a bare command not found. Ideally the image puts a wrapper on PATH so this reads materialize-cursor-harness && bun install.
2. Failure blast radius. With &&, any non-zero exit from the harness script means bun install never runs — you lose the entire dev environment, not just the skills. Since the harness is a convenience layer and bun install is the actual requirement, consider decoupling: materialize-cursor-harness.sh || echo "warn: harness materialization failed"; bun install.

🟡 Reproducibility: tag pin vs. digest, and --frozen-lockfile

v1.0.0 is a mutable tag — it can be re-pushed to a different digest at any time, silently changing what your agents execute. Given the image supplies skills and commands the agent runs, a digest pin is the stronger guarantee:

FROM ghcr.io/prashamtrivedi/cursor-dev-setup:v1.0.0@sha256:<digest>

Similarly, bun install will happily drift from bun.lock; bun install --frozen-lockfile matches the reproducibility goal of this PR.

🟢 Nit: build context is wider than needed

"build": { "dockerfile": "Dockerfile", "context": ".." }

The Dockerfile is a single FROM with no COPY/ADD, so the context is never read — but it still gets tarred and shipped to the builder. From the repo root that includes .git/, node_modules/ if present, bun.lock (86 KB), package-lock.json (188 KB), and worker-configuration.d.ts (294 KB). Either narrow it to "." (the .cursor/ dir), or add a .dockerignore if you plan to add COPY steps later.

---

Testing

Infra-only change, so no unit tests apply — but nothing in CI validates .cursor/, meaning a broken Dockerfile or environment.json only surfaces on the next Cloud Agent rebuild. A tiny workflow gated on paths: ['.cursor/**'] that runs docker build -f .cursor/Dockerfile .cursor would catch pull failures and typos at PR time.

Two additions worth folding into your test plan checklist:

• Confirm bun is actually on PATH in the base image — the old config self-installed it, so this is a new hard assumption. If it's missing, install fails outright.
• Confirm the harness script exists at /opt/prasham-cursor/bin/materialize-cursor-harness.sh in v1.0.0 specifically.

Your existing item about the GHCR image being public is the right first check — if it's private, the build fails with no auth configured anywhere in environment.json.

---

Summary: the base-image approach is the right call. The blockers for me are the dropped D1 migration step and the dropped ui install — both are silent regressions that'll bite the next agent to spin up an environment. The rest is polish.