fix(permissions): stop writing global-only keys into a Cursor project config - #2623
Merged
dyoshikawa merged 3 commits intoAug 7, 2026
Merged
Conversation
… config fromRulesyncPermissions built one identical object for both scopes: it stamped version and editor.vimMode unconditionally and merged the cursor override's approvalMode and sandbox into the top level, while only the filename varied. Cursor documents the opposite - only permissions can be configured at the project level, all other CLI settings must be set globally - so a cursor.approvalMode authored without --global landed in a file Cursor ignores, and the setting silently never took effect. Project scope now contributes only permissions and warns for each global-only override key, naming it and pointing at --global. Existing project-file content still passes through untouched, including a version an earlier version stamped, since rulesync cannot tell its own key from a hand-written one. The scope-specific merge moves into a helper to stay under the complexity limit.
…rning Re-scoping left two tests asserting behavior their scope no longer runs: the version and editor.vimMode preservation checks passed on a plain spread, so the managed merge went untested. They now target the global file, a project counterpart covers the pass-through, and the duplicated version-stamping test is dropped. The warning no longer names version, editor or permissions. rulesync re-applies its managed value over those in global scope too, so telling the user --global would help was a false promise. The editor narrowing moves into the global branch, where editor is actually managed; in project scope it warned about ignoring a value that was in fact passed straight through. Also record that the configuration reference marks version required without scoping it to a file, and that import stays scope-blind on purpose so a project config carrying these keys does not lose them.
…he value The non-object editor branch had no coverage either before or after the extraction, so nothing stopped the project-scope false warning from coming back.
dyoshikawa
deleted the
resolve-issue-2399-cursor-project-scope-permissions
branch
August 7, 2026 17:35
This was referenced Aug 7, 2026
Merged
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fromRulesyncPermissionsbuilt one identical object regardless of scope -getSettablePathsswitched only the filename. It stampedversion: 1andeditor.vimModeunconditionally and merged thecursoroverride'sapprovalMode/sandboxinto the top level.Cursor documents the opposite: "Only permissions can be configured at the project level. All other CLI settings must be set globally." So a
cursor.approvalModeauthored without--globallanded in a.cursor/cli.jsonthat Cursor ignores, and the setting silently never took effect - the failure was invisible, since the file looked correct.Changes
permissionskey. Global behavior is unchanged.--global. The check is over all override keys, not a hardcodedapprovalMode/sandboxpair, since the override is alooseObjectand any futurecli.jsonkey authored there has the same problem.versionan earlier Rulesync stamped there. Rulesync cannot tell a key it wrote from one you wrote, so deleting it would be destructive; the docs say so explicitly.oxlintcomplexity limit.Note on the test changes
Five existing tests asserted
version,editor.vimMode,approvalModeandsandboxlanding in a project config - the behavior being removed. They are re-scoped toglobal: true, where those assertions are still exactly right, rather than deleted. New project-scope coverage:version/editorabsent, the override keys skipped, the warning naming both keys and--global, and a negative test that nothing is warned when the override has no global-only keys.Verified locally with the permissions e2e spec.
Part of #2399
The issue's BUGBOT.md and
permissions.jsonchecks items are design-gated and untouched.🤖 Generated with Claude Code