Harness · Cursor

Cursor on the Software Lifecycle Cloud

Cursor on KERNSTACK means the Cursor editor and its coding agents working in a KERNSTACK repository: handler code under functions/ and workers/, the frontend under apps/, and the stack.json that declares how all of it runs. Cursor supplies the editing and the agents; KERNSTACK supplies the governed target — agent branches with their own environments, a machine-readable plan, and a deploy gate a person controls.

Agent Sandboxes Hosted Git stack.json IaC

Talk to us Read Technical Documentation → Software Lifecycle Cloud →

What Cursor does in a KERNSTACK project

The working unit is an ordinary repository, which is what Cursor is built for. Composer or another model edits code and stack.json side by side: add a route and the gateway entry appears in the same diff, add a table and the seed file lands beside it. Because the whole application is declared in one file, the agent’s change is legible in the editor’s diff view instead of being spread across a cloud console the IDE cannot see.

When Cursor’s agents run tasks in the background, their work belongs on branches — and KERNSTACK hosted git gives agent work its own namespace. Demos and sandboxed attempts live on agent/ branches, deployable to the matching agent- environment, so an experiment gets a real URL without ever touching main.

The review checkpoint Cursor cannot give itself

An editor agent can write anything; the question is what may ship. On KERNSTACK the shipping path runs through kernstack plan, which shows creates, updates, and deletes — and refuses destructive changes until a human passes the confirmation flag. A project can also set a deploy gate (min_source_assurance) so deploys require review-approved source, turning “the agent said it works” into “a person approved this exact plan.”

Check an agent’s work out locally: kernstack git checkout agent/ pulls the exact branch it built on
Keep the work by moving it to a feature/ branch, which kernstack use offers when you leave an agent branch
Deploying an agent branch outside its own agent environment asks for confirmation — the sandbox boundary is enforced, not suggested

Supported Models & Workflow

Supported Models & Engines: Composer · Grok · Claude · GPT — your choice in Cursor

Cursor — Developer & Agent Workflow cli · sandbox

In Cursor: agent edits code + stack.json on agent/<id>
Terminal: kernstack plan --json (read the diff)
Approve in the editor, then: kernstack deploy
main is never touched by the agent branch

stack.json — Governed Target Stack plan · deploy

{
  "stack": { "target": "prod" },
  "gateway": { "routes": [] },
  "resources": {}
}

FAQ

Frequently asked questions

Do we need a Cursor-specific KERNSTACK integration or plugin?

No special integration is required. Cursor works in the repository: code, stack.json, and the kernstack CLI in the integrated terminal. The platform side — hosted git, branch environments, plan and deploy gates — is what makes the agent’s output governable once it leaves the editor.

Which models can we use with Cursor on KERNSTACK?

Whichever models your Cursor setup offers — Composer, Grok, Claude, GPT, and others. KERNSTACK is model-agnostic because it never sees the editing session; it sees branches, plans, and deploys. Model choice stays a Cursor decision and can change per task.

How do we review what a Cursor agent changed?

At two checkpoints: the branch diff in the editor or on hosted git, and kernstack plan, which translates the change into platform language — resources created, updated, or deleted. Destructive entries stop the deploy until a person confirms them explicitly.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →