Cursor Starts Cloud Agents Without Repos

@cursor published an August 27, 2026 changelog for Cursor, Anysphere's AI code editor, that lets Cloud Agents start from scratch without connecting GitHub or another third-party SCM first. It deals with a common bit of friction: you have an idea worth exploring, but not yet a repo worth creating. The takeaway is simple: use the new path for bounded prototypes, then add cursor rules and human review before treating the generated Origin repo as real.

Start from scratch is a Cloud Agents entry path that lets you prompt first, preview the build in the browser, and save the work to a Cursor Origin repo later. That makes it especially interesting for people already thinking about Cursor subagents and skills, because scratch space is where a lot of agent workflows begin before they deserve a permanent home.

Start prompting before Git gets involved

The changelog adds a new choice in the repo picker: Start from scratch. Pick it, prompt the Cloud Agent, and Cursor creates the working project in the background instead of requiring you to connect a GitHub repo or other SCM provider up front.

That changes the first five minutes of a build. A developer can ask for “a small Next.js pricing calculator with persisted inputs and a CSV export” without first naming a repository, setting remote visibility, or deciding where the experiment belongs.

The trap is treating “no repo required” as “no boundaries required.” A scratch build still needs a clear prompt. Give the agent a small product shape, a stack preference, and one thing it must not do, such as “do not add auth” or “do not introduce a database.”

Save the version that earned a repo

Once the agent’s build looks useful, the changelog says you can click Create repo to save it as a fully scaffolded Cursor Origin repo. Cursor lets you choose a custom name or use a suggested one, then set visibility to private or internal. After that, the repo is available from the Codebase tab.

This is the most important product choice in the release. The repository is no longer the entry ticket. It is the receipt for work that survived a first pass.

The honest limit is that saving a repo is not the same as blessing its architecture. A generated scaffold may compile and still have the wrong dependency shape, weak tests, or unclear ownership. Treat the first Origin repo as a draft with file history, not as finished software.

Preview the cloud build in the browser

Cursor also added browser access to the Cloud Agent’s live environment through port forwarding. In plain terms, the app the agent is building can be previewed from the browser while it is still running in the cloud environment.

That matters because many scratch projects are visual. A form flow, a landing page, a chart, or a settings screen is hard to judge from a file diff alone. The changelog also calls out Design Mode, which fits this loop: inspect the live thing, ask for a change, inspect again.

The trap is reviewing only the preview. A good-looking UI can hide brittle state, exposed secrets, or a dependency nobody wants to maintain. If the prototype touches user input, uploads, auth, or permissions, pair the browser pass with a code pass. For security-heavy prototypes, the habits in VibeGuard Security Linting for AI Code are a useful companion.

Publish only when the demo needs a URL

The release also adds a publish path: connect a Vercel account and publish the work to get a live URL. Cursor is explicit that a Vercel account is required for this feature.

That is a nice fit for demos. A product manager, designer, or teammate can try the build without asking you to zip a folder or screen-share a dev server.

The limit is also clear. Publishing makes a prototype reachable; it does not make it production-ready. Before you publish, remove fake secrets, check environment variables, and decide whether the URL is meant for one reviewer or a wider audience.

Try it beside one real repo

The safest first experiment is not a greenfield dream app. It is a small companion to a repo you already understand.

Pick one existing repo and choose a feature adjacent to it, not inside it. For example, if your real repo is an internal billing service, ask Cloud Agents to start from scratch with “a tiny invoice dispute triage UI using mocked data, no backend, no auth, and three states: new, investigating, resolved.”

Then compare the result against the real repo’s boundaries. If your project already uses Cursor Rules, an AGENTS.md file, cursor skills, or a cursor custom agent note, copy only the relevant constraints into the scratch prompt. Do not dump the whole repo’s history into a prototype.

A small boundary file can help you decide what survives the trip back into real work:

# AGENTS.md

## Scratch prototype boundary

This project is a disposable UI prototype for invoice dispute triage.

Allowed:
- Use mocked JSON data in the repo.
- Build a single-page flow with clear loading and empty states.
- Add lightweight tests for state transitions.

Not allowed:
- No production API calls.
- No auth, billing writes, or customer data.
- No new design system package.

Review before keeping:
- List dependencies added by the agent.
- Confirm every route is mock-only.
- Name the files worth moving into the real billing repo.

This is not ceremony. It is a cheap way to keep the scratch repo honest.

Try it safely checklist

Use this checklist for one scratch Origin repo, not a broad process.

• Start from the repo picker with Start from scratch.
• Prompt for one thin slice: one user, one flow, one success state, one failure state.
• State the stack and the non-goals in the first prompt.
• Preview the live environment in the browser before saving the repo.
• Click Create repo only after the prototype has a reason to exist.
• Use a private or internal visibility setting unless the work is intentionally public.
• Open the Codebase tab and review generated files, dependencies, scripts, and environment assumptions.
• Add a tiny AGENTS.md or .mdc rule before the second serious prompt.
• Publish with Vercel only if a live URL is needed.
• Before moving anything into an existing repo, copy code intentionally instead of merging the whole scaffold.

A minimal .mdc rule for the second prompt can be enough:

---
description: Applies to scratch Cloud Agent prototypes before they are kept
---

Keep this prototype mock-only until a human reviewer approves real integrations.
Prefer small components, obvious names, and tests around state changes.
Before adding a dependency, explain why the standard library or existing framework is not enough.

Common questions

• Does Cursor Cloud Agents now work without GitHub?

  Yes, the August 27, 2026 changelog says Cloud Agents can start without connecting GitHub or another third-party SCM provider. You select Start from scratch in the repo picker, prompt the agent, and Cursor handles the background project path before you decide whether to create an Origin repo.

• What is Cursor Origin in this flow?

  Cursor Origin is the repo destination Cursor uses when you decide to keep the scratch work. In this release, the Create repo button turns the agent’s build into a scaffolded Origin repo with a chosen or suggested name and private or internal visibility, then makes it available from the Codebase tab.

• Can I preview what the Cloud Agent built before saving it?

  Yes, the changelog says Cursor port-forwards the Cloud Agent’s live environment to your browser. That means you can inspect the running app, use browser-based review habits, and try Design Mode before deciding whether the generated project deserves a repo.

• Do I need Vercel to publish the scratch project?

  Yes, Cursor says a Vercel account is required for the publish feature. Saving to Cursor Origin and publishing are separate decisions: Origin keeps the scaffolded repo, while Vercel gives the built work a live URL when a demo or review link is useful.

• Where do cursor subagents and skills fit here?

  They fit after the first rough shape exists. Use scratch mode to explore the idea, then add a focused rule, cursor skill, or cursor subagent note for repeatable review tasks such as dependency checks, UI copy cleanup, or migration planning. Do not over-structure the first prompt.

Best ways to use this research

• Best for: understanding what Cursor’s repo-less Cloud Agents start changes in the first few minutes of a prototype.
• Best first artifact: a tiny AGENTS.md or .mdc boundary that says what the scratch repo may and may not do.
• Best comparison angle: compare “prompt first, save later” against the older habit of creating or connecting a repo before the idea has earned one.
• Best review habit: inspect the browser preview for behavior, then inspect the Codebase tab for dependencies, scripts, and integration assumptions.

Further reading

• @cursor — source
• Cursor — Agent
• Cursor — Rules

Next step

Try one scratch Cloud Agent build for a disposable companion feature, then save it only if the preview teaches you something worth keeping. Before the second prompt, add a small boundary file so the agent knows what not to touch.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.