Skip to content

fix: close os_check mode bypass - #37

Draft
cursor[bot] wants to merge 2 commits into
mainfrom
cursor/critical-correctness-bugs-d25b
Draft

fix: close os_check mode bypass#37
cursor[bot] wants to merge 2 commits into
mainfrom
cursor/critical-correctness-bugs-d25b

Conversation

@cursor

@cursor cursor Bot commented Jun 6, 2026

Copy link
Copy Markdown

Summary

  • Remove the caller-controlled mode parameter from os_check and fix it to refactor-mode grants, preventing refactor agents from bypassing the new trust-grant check by omitting mode or passing build.
  • Restore Anthropic as the web UI default provider so the default browser path does not select chat-only Ollama agents with no tools.

Validation

  • python3 source regression checks confirmed the mode argument/default bypass is gone and Anthropic is selected by default.
  • Served src/web locally and verified the delivered page selects Anthropic.
  • Recorded browser walkthrough: /opt/cursor/artifacts/web_default_provider_anthropic.mp4.
  • lex check . could not run because the lex CLI is not installed in this environment.
Open in Web View Automation 

alpibrupa and others added 2 commits June 6, 2026 09:23
- lex.toml: switch to git deps
- src/agents/*: build, explore, plan, refactor, review, spec, test agents updated
- src/permissions/rules.lex, manifests.lex: permission rules and manifests
- src/tools/index.lex, os_check.lex: tool index and OS check tool
- src/server/web.lex: web server
- src/web/index.html: updated UI

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: alpibrupa <alpibrupa@users.noreply.github.com>

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Security review complete. I found one medium-severity supply-chain issue introduced by this PR. There were no prior unresolved automation threads to carry forward.

Open in Web View Automation 

Sent by Cursor Automation: PR Lex

Comment thread lex.toml
Comment on lines +7 to +13
lex-llm = { git = "https://github.com/alpibrusl/lex-llm" }
lex-agent = { git = "https://github.com/alpibrusl/lex-agent" }
lex-trail = { git = "https://github.com/alpibrusl/lex-trail" }
lex-spec = { git = "https://github.com/alpibrusl/lex-spec" }
lex-schema = { git = "https://github.com/alpibrusl/lex-schema" }
lex-os-manifest = { git = "https://github.com/alpibrusl/lex-os-manifest" }
lex-web = { git = "https://github.com/alpibrusl/lex-web" }

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: Medium. These new git dependencies are not pinned to immutable commits/tags, and this repo has no lockfile. A future or compromised upstream commit can be pulled by lex pkg install/CI without any change in this repo, letting attacker-controlled dependency code run in builds and developer installs. Pin each git dependency to a reviewed revision or commit the resolver lockfile.

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found and fixed one critical os_check correctness/security issue in follow-up PR #38: #38

Bug and impact: when os_check detects a forbidden refactor-mode effect such as net, it returns Ok(JStr("GRANT VIOLATION ...")). The tool dispatcher treats Ok as a successful tool call, so an agent or automation that gates on tool failure can silently continue after a failed grant check. A concrete trigger is a refactor-mode edit that adds a [net] effect, then runs os_check on that file; the output says GRANT VIOLATION, but the call is still marked successful.

Root cause: the new grant-check tool encoded policy failure in a success string, and extract_effects also treated missing/malformed data.required_effects as an empty effect list, producing a false pass when the JSON shape could not be proven.

Fix and validation: PR #38 makes grant violations return Err(..., "grant_violation", ...) and makes missing/malformed required_effects fail closed. I validated with lex check src/tools/os_check.lex, lex fmt --check src/tools/os_check.lex, and Python source regression checks for the fail-closed paths. A full src/ check still fails in unrelated src/server/api.lex with an effect-row mismatch, so I did not treat that as validation for this patch.

Open in Web View Automation 

Sent by Cursor Automation: Quality of PR Lex

Comment thread src/tools/os_check.lex
if list.len(violated) == 0 {
Ok(JStr(str.concat("grant check passed [mode=", str.concat(mode, str.concat("] effects=", str.join(required, ","))))))
} else {
Ok(JStr(str.join([

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a critical policy-check bypass: the tool reports a refactor grant violation as Ok(...), so the dispatcher records a successful tool call even when forbidden effects were found. A refactor agent can add a [net] effect, call os_check on the edited file, receive GRANT VIOLATION, and still have the tool invocation complete successfully for any caller/automation that gates on tool errors. I opened follow-up PR #38 to make this path return Err(..., "grant_violation", ...) and to fail closed on malformed/missing required_effects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants