Skip to content

docs(config): document saved ask rules from approvals#3460

Merged
Hmbown merged 1 commit into
Hmbown:mainfrom
greyfreedom:codex/docs-ask-rule-persistence
Jun 23, 2026
Merged

docs(config): document saved ask rules from approvals#3460
Hmbown merged 1 commit into
Hmbown:mainfrom
greyfreedom:codex/docs-ask-rule-persistence

Conversation

@greyfreedom

Copy link
Copy Markdown
Contributor

Summary

Document the current persistence behavior for ask rules created from approval cards.

Scope

  • Replace the stale statement that approval UI persistence is unsupported.
  • Document that S is available only in exec_shell approval cards.
  • Clarify that S approves once and persists an ask rule containing the approved command.
  • Document that saved command rules use the existing arity-aware prefix matching.
  • Clarify that file-path ask rules can be authored in permissions.toml and matched at runtime, but cannot yet be saved through the approval UI.

Not in this slice

  • Typed allow/deny rules.
  • Glob expansion.
  • File-rule creation from the approval UI.
  • Changes to runtime approval or persistence behavior.

Builds on

  • The landed ask-only permissions.toml schema and runtime wiring.
  • The landed approval-card persistence for exec_shell ask rules.

Issues

Refs #1186 (partial)
Refs #2242 (partial)

Validation

  • cargo fmt --all -- --check
  • git diff --check

Clarify that the approval card's S shortcut is available only for exec_shell and persists the approved command as an ask rule. Document the existing arity-aware command matching and distinguish manually authored file-path ask rules from UI persistence, which is not supported yet.
@greyfreedom greyfreedom requested a review from Hmbown as a code owner June 23, 2026 08:02
@github-actions

Copy link
Copy Markdown

Thanks @greyfreedom for taking the time to contribute.

This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered.

Please read CONTRIBUTING.md for the expected contribution shape. A maintainer can grant recurring PR access by commenting /lgtm on a pull request.

@Hmbown

Hmbown commented Jun 23, 2026

Copy link
Copy Markdown
Owner

Thank you!! Just a heads up - I am going to revert "yolo" mode back to having complete freedom - if there's a certain middle ground you're hoping to get between agent and yolo mode, I'll do my best to figure out how to configure that.

@Hmbown Hmbown merged commit 03b6953 into Hmbown:main Jun 23, 2026
10 checks passed
@greyfreedom

Copy link
Copy Markdown
Contributor Author

Thank you!! Just a heads up - I am going to revert "yolo" mode back to having complete freedom - if there's a certain middle ground you're hoping to get between agent and yolo mode, I'll do my best to figure out how to configure that.

Thanks for the heads up. I agree that yolo should keep its existing “full freedom” semantics and should not be constrained by typed ask rules or approval prompts. I’ll treat the permission-rule work as applying to the safer approval modes only.
If there is a useful middle ground between agent and yolo, I think it should be introduced as an explicit configuration or mode rather than changing what yolo means. I’m happy to follow your lead on the naming and semantics if/when we slice that out.

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