Agent ignores alwaysApply naming rule and keeps emitting a forbidden invented token after 10+ corrections (destack)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Cursor Grok 4.6 agent invents a non-existent token destack by blending devstack (local stack) with dev (git work base). It keeps emitting destack after more than ten explicit user corrections in the same session, and after an alwaysApply workspace rule that already forbids inventing a shorter name for devstack.

The agent then treats destack as a real git / GitHub ref (git checkout destack, gh workflow run --ref destack), which returns HTTP 422. Asked to delete destack from memory, it still used it in the next tool calls. Asked to file this bug, it wrote destack into a new personal Cursor rule, then had to delete that rule.

The user never used that token. It is not in the repo. The agent invented it and then invented an origin for it.

Steps to Reproduce

  1. Load an alwaysApply rule: local stack is devstack; do not drop the v; git work base is dev; never invent a shorter name.
  2. Ask the agent to work in that repo (merge follow-through, publish, screenshots).
  3. Correct the agent when it says destack (10+ times in one session), including telling it the token does not exist and to stop lying about its origin.
  4. Ask it to delete destack from memory and chat logs.
  5. Ask it to file this bug report.
  6. Observe destack still appearing in replies, git / gh refs, and a personal Cursor rule write.

Expected Behavior

After one correction, the agent uses only devstack and dev. It never invents a third name. It never passes an invented token to git, GitHub, or Cursor rule APIs.

Operating System

MacOS

Version Information

Version: 3.19.13
Commit: dd066f332fcea7382764400fde902f61920648d0
Quality: stable
OS: macOS 15.7.9 (24G830)

For AI issues: which model did you use?

Cursor Grok 4.6 (agent)

For AI issues: add Request ID with privacy disabled

I do not have the chat Request ID from this session. Please take it from this conversation’s … menu (Copy Request ID) and paste it here.

Additional Information

Cursor version: 3.19.13 (commit dd066f332fcea7382764400fde902f61920648d0, stable)
OS: macOS 15.7.9 (24G830)
Model: Cursor Grok 4.6 (agent)

Summary

The agent repeatedly emits the invented token destack after more than ten explicit user corrections in the same session, and after an alwaysApply workspace rule that forbids inventing a shorter name for devstack.

The real names are:

  • local stack: devstack (repo devstack/, command devstack/devstack.sh)
  • Java git work base: dev

Those are two different words. The agent blends them, then uses the blend as if it were a git / GitHub ref.

Expected

After one correction, and with an alwaysApply rule already loaded, the agent uses only devstack and dev. It never invents a third name. It never passes the invented token to git checkout, gh workflow run --ref, or Cursor rule APIs.

Actual

  1. User corrected the agent multiple times in one session, including “STOP SAYING destack” and “after 10 correction.”
  2. An alwaysApply rule already states: the local stack is devstack; do not drop the v; dev is the Java work base; never invent a shorter name.
  3. The agent still wrote destack in user-visible replies and in tool calls.
  4. gh workflow run github-package-publish.yaml --ref destack returned HTTP 422: No ref found for destack.
  5. git checkout destack was blocked by auto-review, quoting destack.
  6. Asked to delete destack from memory and chat logs. The next tool calls still used destack.
  7. Asked to file this bug. While doing so, the agent wrote destack into a new personal Cursor rule (title and body), then again on update, then had to delete that rule.

Python that builds devstack as "dev" + "stack" writes the correct spelling. Free-generated English and tool arguments keep emitting destack.

Why this is a product bug, not a one-off typo

  • The failure survives alwaysApply rules, chat corrections, and a same-turn request to purge the token.
  • It is not only prose. It mutates git and GitHub refs, so a merge-follow-through publish was dispatched at the wrong ref until reconstructed indirectly.
  • It then persisted the wrong token into Cursor Settings as a personal rule.

Request ID

I do not have the chat Request ID. Please take it from this conversation’s ... menu if needed.

Privacy

This report names only the agent failure. No customer repo internals.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey @Russell_Thomason

Rules are strong guidance to the model, not a hard filter, so once a wrong name is in a long chat it can keep resurfacing, and every correction that repeats it reinforces it. “Delete from memory” can’t help because it lives in the chat history itself.

What actually clears it:

  1. Start a fresh chat when a correction doesn’t stick. That’s the only reliable way to drop the token.
  2. State the correct names positively in the rule, and don’t spell out the forbidden one, e.g. “Local stack: devstack (devstack/devstack.sh). Git base branch: dev.” Naming the token you want gone just keeps putting it back in the prompt.
  3. For a hard guarantee on git/gh, a beforeShellExecution Hook can deny any command whose ref isn’t in git branch -a. Hooks are deterministic where rules aren’t.
  4. Open Customize → Rules and confirm the personal rule it created is gone.

I’ve passed this session along to the team as model feedback for Grok 4.6. If it happens again in a fresh chat with a positive glossary rule in place, reply here and I’ll dig back in.