Cursor Projects Subscriptions: Slack, GitHub, Linear and Scheduled Agent Workflows

01

Overview

Cursor Projects can do more than run a long sequence of coding tasks. Through Cursor’s subscription system, a cloud agent can pause, wait for something to happen and then continue in the same conversation with the context it already built.

That event-driven behavior is what makes a Project useful for recurring engineering work such as following pull requests, reacting to CI failures, waiting for a teammate in Slack or running maintenance on a schedule.

Subscriptions existed as a Cloud Agent capability before the September 10, 2026 Projects launch. Projects makes them more useful by placing them inside a persistent project-level workflow with shared context and a coordinator.

02

What is a Cursor subscription?

Cursor’s documentation describes a subscription as an event-driven wait. A cloud agent subscribes to a supported event, ends its current turn and wakes when a matching event arrives.

The important detail is continuity: Cursor says the agent resumes the same conversation with its existing context. That is different from starting a brand-new automation run that has to reconstruct the task from scratch.

Cursor currently documents subscription sources for GitHub, Slack, Linear and timers.

03

GitHub subscriptions

GitHub subscriptions are useful when agent work depends on what happens after code is pushed.

Cursor documents pull-request activity such as reviews, comments, status changes and CI events. A cloud agent can create a pull request, wait for feedback, and continue when a review or failure appears.

Cursor also documents automatic attempts to fix CI failures on pull requests created by Cloud Agents. The exact behavior and supported CI surface should be checked against current documentation; the capability is not a guarantee that every test failure can be diagnosed or repaired automatically.

A practical Project workflow can look like this:

1. the coordinator delegates an implementation;
2. an agent opens a pull request;
3. the agent subscribes to relevant PR or CI activity;
4. the conversation pauses;
5. CI fails or a reviewer comments;
6. the agent wakes with the same context, investigates and proposes a fix;
7. a human still reviews the resulting changes.

This can remove the need for a developer to repeatedly prompt the agent to “check the PR again.”

04

Slack subscriptions

Slack subscriptions let an agent wait for human input or react to messages.

Cursor documents patterns including waiting for a reply in a Slack thread and watching channel messages. Projects gives this a clear use case: a long-running engineering project can watch a bug-report or support channel and use relevant messages as triggers for investigation.

For example, a Project responsible for a feature could monitor a designated bug-report channel after release. When a relevant message appears, the coordinator or delegated agent can investigate the codebase and prepare a proposed change.

This should not be treated as permission to let an agent act on every Slack message indiscriminately. Use narrow channels, clear trigger criteria and review requirements so normal conversation does not become production work by accident.

05

Linear subscriptions

Cursor’s Cloud Agent documentation also lists Linear issue events. An agent can wait for issue-state changes or comments and continue when the relevant event occurs.

That enables workflows where engineering work is coordinated around an issue tracker rather than only GitHub. A Project could pause until an issue is moved into a particular state, until a product manager adds clarification or until an acceptance decision is recorded.

The same principle applies: use the external system as a signal, not as unquestioned truth. The agent should interpret the event within the Project’s existing plan and constraints.

06

Timer subscriptions and recurring schedules

Cursor also supports timers. Documentation includes one-off waits and recurring scheduled behavior, including a /loop workflow for repeated tasks.

This is useful for maintenance that should happen on a cadence: periodic dependency checks, repeated repository hygiene, regression scans or other “gardening” work.

Cursor’s Projects announcement describes recurring work as one of the major use cases. Its internal examples include ongoing code-quality and design-system maintenance.

A schedule does not make the output safe to merge automatically. Recurring agent jobs should still have bounded scope, predictable outputs and review rules.

07

Subscription duration and event behavior

Cursor’s Cloud Agent capability documentation states that subscriptions can last for up to 180 days. That is a current documented limit and should be rechecked before publication because beta infrastructure can change.

The documentation also describes event handling intended to avoid unnecessary repeated wake-ups when events arrive in bursts. Exact behavior should be verified from the current docs when designing a workflow that depends on event ordering.

Do not assume that a subscription is an unlimited permanent daemon. It is a managed wait inside Cursor’s agent system with documented limits.

08

Example: keep a pull request moving

A useful GitHub workflow is to let an agent continue through the normal review cycle instead of stopping as soon as it opens a PR.

The agent implements a bounded task, opens the pull request and subscribes to relevant activity. If CI fails, it can investigate. If a reviewer asks for a change, it can respond to the new information in the same conversation.

The developer still owns approval. The advantage is continuity: the agent remains attached to the work while external systems and people provide feedback.

09

Example: Slack bug triage

A Project can watch a dedicated Slack bug channel. When a new report matches the intended scope, the Project can inspect the relevant code, look for related changes and prepare a diagnosis or pull request.

This is especially useful after a feature launch, when feedback arrives outside the code editor.

Use clear boundaries. A general company chat channel is usually a poor trigger surface because context is noisy and messages may not represent actionable engineering requests.

10

Example: recurring repository gardening

For ongoing maintenance, a Project can use a timer subscription to wake on a schedule, inspect a defined part of the repository and propose bounded improvements.

Cursor uses “gardening” to describe recurring work such as maintaining code quality or enforcing a design system. The company says one internal Project is expected to touch 20 to 100 pull requests per day. That is a vendor-reported internal example, not an independent benchmark or recommended workload.

11

Projects subscriptions vs Cursor Automations

Cursor Automations are also trigger-driven Cloud Agent workflows, so there is overlap.

The useful distinction is context and scope. An Automation is configured around a trigger and instruction. A Project is a persistent body of software work with a coordinator and shared context, and it can use subscriptions to wait for events while pursuing that broader objective.

Because both products are evolving, do not build a rigid taxonomy around current beta wording. Choose the mechanism that best preserves the context and control your workflow needs.

12

Safety and review considerations

Event-driven agents can act while the user is not actively sitting in the editor, which makes permissions and review more important.

Use least-privilege access for Slack, GitHub and other integrations. Keep production secrets out of unnecessary contexts. Limit the repositories, channels and issue sources that can trigger work. Require human review before merging changes with meaningful production impact.

Also distinguish “wake when an event happens” from “correctly understand every event.” The subscription delivers a signal; the model still has to interpret it.

13

FAQ

What can trigger a Cursor subscription?

Cursor currently documents GitHub activity, Slack events, Linear events and timers as subscription sources for Cloud Agents.

Does the agent lose its context while waiting?

Cursor says a subscribed cloud agent wakes in the same conversation with its existing context.

Can Cursor Projects run on a schedule?

Yes. Cursor documents timer-based waits and recurring scheduled behavior, and the Projects announcement explicitly highlights scheduled recurring work.

Can a Project react to GitHub CI failures?

Cursor documents GitHub and CI-related agent workflows, including attempts to fix CI failures on pull requests created by Cloud Agents. Human review remains important.

How long can a Cursor subscription wait?

Cursor’s current Cloud Agent documentation says subscriptions can last up to 180 days. Recheck the live documentation before depending on that limit for a long-running production workflow.

Are subscriptions the same as Cursor Automations?

Not exactly. Automations are trigger-and-instruction workflows; Projects are persistent project-level workspaces that can use subscriptions as part of a larger coordinated objective. The products overlap and may continue evolving.