Stop "Creating the Repo First": Cursor's Cloud Agent Lets You Start with Just a Conversation and Fold It into a Container Later
Cursor's cloud agent can now start building without a GitHub connection. Give instructions from scratch → preview instantly in the browser → save to Origin once you're satisfied, and even get a public URL via Vercel. The entry point to development flips from "container first" to "build first."
For a long time, the assumption on the AI coding front lines has been a specific workflow: "first prepare the repository you want to work on, then connect it to the agent." An update to Cursor's cloud agent, released on August 27, 2026, does away with that very first step. You no longer need to connect a source control service like GitHub in advance—you can now start giving instructions and building right away.
Repository connection is no longer a prerequisite
Until now, running a cloud agent required connecting an existing GitHub or other source control management (SCM) service beforehand. With this update, you can get to work simply by choosing "Start from scratch" on the repository selection screen. When you write your instructions, Cursor automatically spins up a repository behind the scenes on the company's own code platform, "Origin," and accumulates the output there.
Origin is Cursor's in-house hosting for agents, which the company launched in August. This change extends the agent's responsibilities all the way to creating that storage location itself.
From "container first, contents later" to "contents first, container later"
Previously, you prepared the container (the repository) first and only then started writing the contents. The new flow reverses that order. Here is how the workflow breaks down:
- Start: Choose "Start from scratch" in the repository selection and give your instructions right away. No connection setup required.
- Check: The environment the agent is running is forwarded (port forwarding) straight to your browser and displayed. You can also use editing tools like Design Mode.
- Fold it in: Once you're happy with the result, press "Create repo," give it a name yourself or pick from suggestions, decide the visibility as "private" or "internal," and save it as an Origin repository.
During the prototyping stage you have no formal repository, and only once something is worth keeping do you tuck it into a container. This reordering is the heart of this update.
Connecting prototype to publication in one continuous flow
Another highlight is the path to publication. If you connect a Vercel account, you can press "publish" on the spot and assign a public URL to what you've built (this feature requires connecting a Vercel account). Without any local environment setup or deployment configuration in between, you can complete the whole cycle—instruct → preview → public URL—inside the browser.
From a business standpoint, this opens the door to a short back-and-forth in which planners and designers give instructions in their own words, check the working screen on the spot, and share it with stakeholders. It has the potential to shrink the wait time of "asking someone who can build it, having them set up the environment, and only then getting to see it." It seems well suited to a way of working where whoever has the idea can stand up a small internal tool or a screen for validation right then and there.
The governance question behind the convenience
On the other hand, the ease of putting off the container is the flip side of looser governance. The following concerns can be raised:
- Keeping track of output: It becomes easy to lose track of who built what and where they published it. The private/internal choice included, this needs to be reconciled with internal control rules.
- Consolidation onto one platform: The storage gravitates toward Origin and the publishing destination toward Vercel. It's worth keeping in mind that, in exchange for the convenience, dependence on specific services grows stronger.
- The bar for publishing: Because a public URL appears at the press of a button, the risk of insufficiently vetted work going public also rises. You need a clear line on what may be released, and how widely.
Cursor itself provides mechanisms such as visibility selection, but it presupposes that the operating side has decided the rules in advance.
Removing the prerequisite of repository connection may look like a small change in itself. But the significance of replacing the development entry point of "first prepare a container" with "first just build it" is not small. The scope of what we hand off to agents is expanding from the work of writing code to the preparation of storage and publishing destinations.
References: Cursor Changelog: Start from scratch, without a repo / Cursor Changelog / Releasebot: Cursor updates