Cursor Projects beta: control shared context, subscriptions, and delegated agents before rollout

Quick answer

Cursor launched Projects in beta on September 10, 2026, with rollout starting for all users. A Project gives long-running work a coordinator agent, cloud execution, shared file-based context, and subscriptions that can wake the work from events or schedules.

That makes Projects more durable than a one-shot coding prompt, but durability also expands the failure surface. Start with one repository, one task class, and one narrowly filtered subscription. Let the coordinator plan and delegate; require worker agents to produce reviewable diffs, tests, and artifacts; and keep merge, release, and production credentials outside the Project's automatic authority. Treat shared context as an auditable knowledge base, not a secret store or an unquestioned memory.

Who this is for

This guide is for engineering teams and independent developers evaluating Cursor Projects for migrations, feature delivery, recurring maintenance, or full-application work. It is especially useful when a task may continue after a laptop closes, wake from GitHub or Slack, or ask a local agent to run a machine-specific test.

If your main requirement is keeping tool execution on controlled hardware, use the separate Cursor Self-Hosted Machines data-boundary checklist. Projects coordinates durable work; it does not remove the need to define where code, credentials, context, and side effects may travel.

What changed and why now

The official changelog describes Projects as a beta environment for work that can span months. A coordinator plans and delegates but does not write code itself. It can create and manage multiple agents, while the Project runs on its own cloud computer and can continue when the user's laptop is closed.

Agents share context through synchronized files containing research, artifacts, and learnings. Subscriptions can keep a Project watching Slack, following pull requests, or running on a timer. Cursor's Cloud Agent documentation also describes event subscriptions for GitHub pull requests and CI, Slack, Linear, and timers. A subscription belongs to one agent conversation, event bursts may be coalesced, and the agent re-reads the triggering source when it wakes.

Those are useful coordination primitives, but the beta label matters. The safe rollout question is not “how many agents can we start?” It is “can one bounded Project accept one class of work, explain every wake-up, and hand back evidence without silently widening authority?”

A seven-step rollout workflow

1. Define one Project contract

Choose one repository, base branch, task class, owner, expected artifact, spend limit, and stop condition. A good first task is a documentation migration or a test-backed dependency update. Avoid a broad goal such as “maintain the product” because it gives neither the coordinator nor the reviewer a terminal definition.

2. Separate coordinator and worker authority

The coordinator may decompose work, assign agents, summarize progress, and request a local check. Worker agents may edit a named repository and run an allowlisted test set. Neither role should merge, deploy, publish, change billing, rotate secrets, or contact customers during the canary.

Use the same identity discipline as the Qwen Code external-agent delegation checklist: every artifact should show which agent produced it, from which commit, under which permissions.

3. Give shared context a schema

Shared files need ownership and expiry. A small structure is enough:

context/verified/    sourced facts and repository invariants
context/decisions/   accepted choices, owner, date, and rationale
context/runbooks/    executable checks and rollback steps
context/inbox/       unverified observations awaiting review

Each entry should carry a source, observed date, owner, expiry or review date, and confidence. Never place API keys, tokens, customer data, private chat exports, or production credentials in synchronized context. An agent should not promote an inbox note to a verified fact without evidence.

4. Canary one subscription

Start with one filtered GitHub pull-request or CI event, or one low-frequency timer. Record an event ID, source revision, received time, deduplication key, and resulting run ID. Because bursts can coalesce and the agent re-reads the source, the acceptance test should prove that ten rapid updates cause one reconciled decision rather than ten duplicated writes.

Do not begin with a broad Slack channel. Untrusted messages, repeated edits, and ambiguous ownership make it harder to distinguish a legitimate trigger from prompt injection or noise.

5. Bound cloud and local execution separately

Cursor documents Cloud Agents as isolated virtual machines working on separate branches and handing back pull requests. Restrict repository scope, network egress, runtime secrets, ignored paths, model choice, concurrency, and spend for that cloud path.

If the coordinator starts a local agent for a platform-specific test, treat that as a separate authorization boundary. Name the test, workspace root, command set, maximum duration, and returned artifact. A laptop being closed does not imply local tests continue; it only means the cloud Project can continue independently.

6. Require a pull-request evidence gate

Before a result is accepted, verify the base and head commits, diff scope, test command and exit state, generated artifact hashes, unresolved findings, and cost. Review the actual pull request rather than relying on the coordinator summary. Keep branch protection, required checks, and human merge authority enabled.

7. Test stop and recovery paths

Exercise a duplicate trigger, revoked integration, denied repository, exhausted spend limit, failed worker, stale shared-context entry, unavailable local machine, and conflicting pull request. The Project should stop or surface an owned failure. It must not create a second uncontrolled lane, repeat an external write, or treat a partial summary as completion.

Rollout manifest

project / owner / beta checked date:
repository / base branch / allowed task class:
coordinator may / may not:
worker agents may / may not:
shared-context paths / write rule / review date:
subscription source / filter / dedupe key:
cloud model / spend limit / concurrency:
secret classes / egress allowlist / ignored paths:
local handoff trigger / local permissions / timeout:
expected PR / required checks / artifact hashes:
stop conditions / rollback owner:
decision: hold | canary | expand | disable

Decision matrix

Surface	First canary	Evidence required	Stop condition
Event intake	One filtered PR or timer	Event ID, source revision, dedupe record	Duplicate or unexplained wake-up
Shared context	Verified facts plus inbox	Source, owner, review date, diff	Secret, stale fact, or unsourced promotion
Delegated agent	One repository task	Agent identity, branch, diff, tests	Out-of-scope file or tool access
Local bridge	One named platform test	Command, timeout, sanitized artifact	Unreachable machine or broader authority
Merge/release	Human-reviewed PR	Protected checks and head SHA	Missing, stale, or partial evidence

Common mistakes

• Treating synchronized context files as a credential vault.
• Subscribing a noisy Slack channel before proving deduplication and prompt-injection handling.
• Assuming cloud continuity also guarantees that a local machine stays reachable.
• Expanding agent concurrency before measuring accepted-task cost and review load.
• Letting the coordinator's summary substitute for the actual diff, checks, and branch state.
• Describing a beta rollout as generally available production infrastructure.

Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.

FAQ

Is Cursor Projects generally available?

No. Cursor calls Projects a beta and says rollout started for all users on September 10, 2026. Verify availability in the target account before changing a workflow.

Will a Project keep running when my laptop is closed?

The Project's cloud computer can continue. A task that depends on a local agent still requires the local machine and its approved environment to be reachable.

What belongs in shared context?

Versioned facts, decisions, runbooks, research, artifacts, and bounded learnings belong there when they have sources, owners, and review dates. Secrets and unreviewed instructions do not.

Which subscription should I try first?

A narrowly filtered pull-request, CI, or timer trigger is easier to deduplicate and audit than a broad conversational channel. Require one terminal receipt before adding another source.

Sources

• Cursor Projects beta announcement
• Cursor Cloud Agent capabilities and subscriptions
• Cursor Cloud Agents documentation
• Cursor Cloud Agent security
• Cursor Automations help

Originally published on IndieSeek.