HARNESSES AND BROKERS / CODING HARNESS (CLOSED SOURCE)

Cursor

Cursor is one of the most widely used coding agents, and it is not open source. It still belongs in an open stack conversation, because the parts that matter for portability (instructions, tools, and the repository itself) can stay in open formats while the editor stays replaceable.

Technology

What it is

Cursor is an AI code editor built around a coding agent. Its documentation describes it as a coding agent that helps you understand a codebase, plan and build features, fix bugs, and review changes. The application is closed source: the public cursor/cursorrepository on GitHub is for issues and feedback, not the product's code.

Editor, CLI, and cloud agents

The same agent runs in three places. In the editor it has a Plan Mode for scoping larger changes before editing. The Cursor CLI runs it in a terminal with the agent command, with agent, plan, and read-only ask modes, and a print mode (agent -p) for scripts and CI pipelines.

Cloud Agents, formerly called Background Agents, run the agent in isolated cloud VMs. Each one clones the repository from a supported Git provider, works on its own branch, and hands the result back as a pull request. That makes the pull request the review point, which is the right place for it.

Models

Cursor offers models from several providers, including Anthropic, OpenAI, and Google, alongside models of its own such as Composer. Model choice is a setting rather than a rebuild, though the models arrive through Cursor's service and plans. Check the current plan terms before assuming you can bring your own API key.

Rules and AGENTS.md

Project rules live in .cursor/rules as .mdc files, versioned with the code. There are also user rules and, on team plans, team rules managed from a dashboard. Cursor also reads AGENTS.md in the project root and in subdirectories. Putting shared conventions in AGENTS.md keeps them readable by other harnesses too.

MCP and approvals

Cursor connects to MCP servers configured in .cursor/mcp.json for a project or ~/.cursor/mcp.json for every project, over stdio, SSE, or Streamable HTTP. By default it asks for approval before using an MCP tool. Allowlists loosen that for tools you trust.

Where it fits in an open stack

Cursor is a closed harness that speaks open formats at its edges. The code stays in your Git repository, instructions can live in AGENTS.md, and tools can be MCP servers that any other harness can use. Kept that way, switching editors costs a habit change rather than a migration.

Gotchas worth knowing

  • .mdc rules are Cursor specific. A plain .md file in .cursor/rules is ignored, and other tools do not read .mdc. Keep shared guidance in AGENTS.md.
  • Cloud agents need repository write access. They push branches, so scope the access you grant.
  • Model availability follows the plan. Which models you can use, and at what price, is set by Cursor's plans rather than by your provider contracts.

How it scores on openness

  • Replaceable. Moderate. Many models, but through Cursor's service; the editor itself is easy to swap if instructions and tools are in open formats.
  • Inspectable. Weak for the tool itself, since the source is closed. Diffs and plans are visible before they land.
  • Portable. Good when you use AGENTS.md and MCP; weaker for anything kept only in .mdc rules.
  • Bounded. Good by default, since MCP tools need approval; allowlists and auto-review modes loosen it.
  • Grounded. Strong for code: it works in the repository and can run checks.
  • Auditable. Good once work lands as branches and pull requests in your Git provider.

What it is not

Cursor is not open source and not a model. It is a hosted product that runs a coding agent in your editor, your terminal, or the cloud.

Openness scorecard for Cursor

The notes above describe the tool. The score belongs to your deployment of it, because configuration, permissions, and where records are kept decide most of the result. Score each test 0 (absent), 1 (partial), or 2 (demonstrated) for the way you run Cursor, out of 12.

TestQuestionWhat a 2 looks likeEvidence to collect
ReplaceableCan one component be swapped without rebuilding the system?A major component has been swapped, and the work was measured in days, not months.Which component did you last swap, and how long did it take?
InspectableCan a builder understand what runs and why?The exact context, tool calls, and results for each step are exported to storage you own.Where do traces live, what do they contain, and how long are they kept?
PortableCan identity, skills, context, and work move?Identity, skills, and work are files in open formats and have been loaded into a second tool.What have you exported and reloaded somewhere else?
BoundedAre authority and approval requirements explicit?Tool scopes, delegated user identity, and approvals are enforced outside the model and tested adversarially.What stops the agent from taking an action its user could not take?
GroundedDo agents share durable data and semantic meaning?Agents query governed metrics over versioned tables and cite the definition and data version.Which semantic definitions and tables do agents use?
AuditableCan people reconstruct decisions and outcomes?Runs, approvals, and data versions are recorded long enough to reconstruct any decision.Could you reconstruct an agent decision from three months ago?

Score your Cursor setup on the interactive scorecard. It runs in your browser, and you can download the result as JSON or print it.

Where to learn more

Primary sources first. Documentation and specifications move faster than any summary, so treat the links below as the authority and this page as orientation.

Work with Alex