Cursor and OpenAI Codex agent tips: rules and AGENTS.md

Cursor and OpenAI Codex are two popular ways to work with a coding agent, and each rewards the same habit: write your project's instructions down where the agent will read them. This guide collects stable tips from the official documentation of each tool, so you can set up your repository once and get steadier results. Product names, menus, and limits change often, so confirm details in the linked docs.

How do I give Cursor lasting instructions?#

Cursor reads project rules from files in your repository, so the agent starts every task knowing your conventions. The docs describe project rules stored in a rules folder inside the project, plus user level rules in your settings that apply everywhere.

Write rules the way you would brief a new teammate:

• The commands to build, test, and lint.
• Conventions the code follows, such as naming or error handling.
• Things the agent must not touch.
• Where to find examples of the pattern you want repeated.

Keep each rule short and specific. Several small, focused rules are easier for the agent to apply than one long essay.

Read this repository and propose project rules for the agent. Give me a short list of rules in plain Markdown: how to build, test, and lint, the conventions the code follows, and what must never be edited. Mark anything you are unsure about instead of guessing.

What is AGENTS.md and who reads it?#

AGENTS.md is a plain Markdown file in your repository that tells coding agents how to work there. Codex documents it as the way to guide the agent, and Cursor documents it as a simpler alternative to its own rules. The format is described at agents.md, and it is meant to be shared across tools.

A useful AGENTS.md has the same short sections for every tool:

Because it is one file, a team that uses several agents keeps one source of truth. We cover the file and its website cousin llms.txt in making a codebase and a website agent-ready.

Create an AGENTS.md for this repository with sections for setup, checks, conventions, boundaries, and pull requests. Use only commands you can verify in the repository, and keep it under 80 lines. List anything you could not verify at the end.

How should I use OpenAI Codex?#

Codex works as a command line tool and as a cloud agent, and in either form it reads your AGENTS.md and works through a task you describe. The documentation explains that you choose how much freedom the agent has, through approval and sandbox settings, so start with the stricter options and loosen them as you build trust.

Habits that help:

• Give one task with a clear finish line, such as "make this failing test pass".
• Tell it which command proves the task is done.
• Keep the task small enough to review in one sitting.
• Read the diff and run the checks yourself before merging.

In this repository, fix the failing test [test name]. Reproduce it first with [test command], find the cause, make the smallest change that fixes it, and run [test command] again. Summarize what was wrong and what you changed. Do not touch unrelated files.

What are background agents good for?#

Background or cloud agents run a task away from your open editor, so you can keep working while they finish. They suit tasks that are independent, well specified, and easy to check, such as dependency bumps, small bug fixes, and adding tests.

A good background task has:

Because nobody watches the agent work, the review step matters more. Read the diff, check the tests ran, and reject changes you do not understand. The same logic is behind the Approve step in StellarFirm: see approval workflows for AI agents.

Task: [one outcome]. Context: [where the code is and what it does]. Done when: [command] passes and no other files change. Limits: do not rename public functions or add dependencies. Return: a pull request with a short summary, the commands you ran, and anything you were unsure about.

Can I connect tools with MCP?#

Yes. Cursor and Codex can each use MCP servers, the open standard that lets an agent call tools on other services. Each has its own configuration, so follow the official docs for the current format. Add only servers you trust, and give them the least access that works.

StellarFirm runs a public, read only MCP server at https://stellarfirm.ai/mcp. In Cursor you add it with a small entry in the MCP configuration file, and the exact JSON is on the MCP server page. It can answer questions about StellarFirm and search its docs. It cannot sign anyone up, send anything, or approve anything. Our MCP guide explains the concepts.

How does this work with the StellarFirm Coder?#

If you already work in Cursor or VS Code, the StellarFirm desktop app lets the Coder meet you there. It can open a file in your editor and apply a change to a project folder you choose on your own computer. Changes land as ordinary edits, so your editor's undo and version control show what happened, and publishing still waits for your Approve. See Cursor and VS Code.

Coder, fix [problem] in the project I have open and apply the change in my editor. Show me the diff in Jobs. Open a pull request only after I Approve.

Whichever tool you use, the pattern is the same: write the rules once, give small tasks, and review what comes back. For StellarFirm specifics, start with your first week with the Coder.