Cursor Rules in Codex: Translate and Check Their Scope

To use Cursor rules in Codex, translate the relevant instructions into AGENTS.md and verify that Codex loads the intended file. Copying a Cursor rule file alone does not establish the same scope or activation behavior in another tool. Start with one rule and check the result before moving your full collection.

Tools like fenbs keep approved project decisions and progress outside either coding app, while local instruction files explain how to work in the repository. That division helps when a teammate changes tools halfway through a task. For the broader differences between the two products, read Cursor vs Codex.

How do you move the first rule safely?

1. Choose one instruction you already rely on, such as preserving keyboard access when changing a form. Note whether it applies everywhere or only to the web app.
2. Separate its actual instruction from its Cursor settings. Keep the instruction, its reason, and a useful example; record the original activation conditions separately.
3. Write the shared instruction in an appropriate AGENTS.md. Keep repository rules at the root and specialized guidance close to the relevant part of the project.
4. Start a fresh Codex session in the intended directory. Ask which instruction files were loaded and what the selected rule requires. Request an explanation without edits.
5. Try a small representative task, review the proposed change, and compare it with your acceptance criteria. Repeat outside the intended scope to catch rules that spread too far.

For example, imagine a studio with a website and a separate image-processing service. A form rule belongs with the website. Turning it into a vague repository-wide requirement could confuse work on the service, even though the original instruction was useful.

What needs translating besides the wording?

Cursor stores project rules as .mdc files under .cursor/rules. Their metadata controls whether they apply broadly, match file patterns, are selected by relevance, or need a manual mention. Those settings belong to Cursor’s rule system; they are not portable instructions by themselves. See the official Cursor rules documentation↗ (opens in a new tab).

Do not copy the metadata block and assume that its meaning follows it. Write the condition as an ordinary sentence a teammate could understand. The Cursor rule examples can help you identify useful instruction text; the conversion still needs a separate scope check.

Where should a rule for one directory go?

OpenAI’s AGENTS.md guide↗ (opens in a new tab) describes startup discovery from the project root down to the current working directory, alongside global guidance. More specific files appear later. Within a directory, AGENTS.override.md takes priority over AGENTS.md. Check the launch directory rather than assuming every nested instruction file was loaded.

A directory condition also needs to be readable inside the instruction. The example below is a proposed arrangement for a small repository, not a command to overwrite existing guidance. Merge it with the rules your team already maintains.

# AGENTS.md at the repository root

Use the package manager recorded in package.json.
Before editing a package, read its local AGENTS.md if present.
Report which checks actually ran and what remains unverified.

# apps/web/AGENTS.md

Scope: changes inside apps/web.
Preserve visible labels and keyboard access when editing forms.
If changing a shared form component, inspect its existing callers first.

Directory placement cannot express every file pattern. If a rule applies to scattered files, state the condition clearly in a shared instruction and require the assistant to inspect the relevant guide. Keep pattern design in the separate guide to Cursor rule globs.

For a decision such as which form behavior the team approved, keep the current answer in fenbs Decisions and rules. The repository instruction can explain when to consult that record instead of maintaining another account of the decision.

How can you tell whether the conversion works?

Use two checks: whether the instructions were discovered, and whether they produce the expected work. Ask for the loaded instruction sources in a fresh session. Then give a small task that requires the rule and inspect the output yourself. A model saying it understands is only the first check.

List the instruction files loaded for this session.
Read the local guidance for apps/web before answering.
Explain what the form-accessibility rule requires for this task.
Identify any conflicting guidance or missing referenced files.
Do not edit files or run project commands.

Test the boundary as carefully as the positive case. A request to explain an image-processing function should not turn into a form audit. If the assistant applies unrelated guidance, narrow the wording and repeat the check in another fresh session.

Save the result and any remaining scope checks with the task in fenbs, so another assistant can continue from the evidence you already gathered.

Why might a copied instruction still fail?

Look for a missing file, a conflicting instruction, or a condition that disappeared during translation. A useful path on one machine can be meaningless on another. References also need clear instructions about when to read them; a filename alone does not explain its purpose.

Long instruction collections deserve a separate check. OpenAI documents configurable instruction discovery limits and fallback filenames in advanced configuration↗ (opens in a new tab). Confirm what reached the session before trying to solve a loading problem with stronger wording.

Keep tool settings separate from agreements about the work. A written request to ask before a sensitive action does not configure the application’s permissions. Review those controls independently when changing apps, and preserve the human approval your project requires.

How to do this with fenbs

1. Create a free account, then add the project whose rules you are moving. It is free for one person, with no credit card.
2. Add a task describing the rule conversion. Put the affected files, scope checks, and expected behavior in its plan.
3. Record the decisions a person approved in Decisions and rules. Save a reusable conversion request in Skills and prompts if you expect to repeat the work.
4. Connect Cursor and Codex using the integration guides. MCP is a standard way for an AI app to use an outside tool; each supported connection signs in through the browser.
5. Ask the outgoing assistant to save progress, then have the next assistant read the project context. Check that it can distinguish completed conversions from untested ones.

fenbs does not convert .mdc files or enforce local instruction loading. A single repository file may be enough when all you need is static guidance. Its value grows when decisions and task progress need to stay available across sessions and tools.

What should you maintain after the switch?

Choose one home for each shared instruction and review future changes there first. Cursor also documents AGENTS.md support, which can reduce duplicated plain-text guidance. Keep any remaining Cursor-specific activation settings separate and check both tools after an important change.

Start the next conversion only after the first rule passes its positive and boundary checks. The wider guide to switching AI tools covers related handoffs. A small, verified set of instructions is easier to maintain than a copied collection whose actual reach nobody has checked.