feat(policy): Introduce config-based policy engine with TOML configuration by allenhutchison · Pull Request #11992 · google-gemini/gemini-cli

allenhutchison · 2025-10-24T21:18:47Z

Config-Based Policy Engine

This PR introduces a flexible, extensible policy engine that allows users and administrators to define tool execution policies via TOML configuration files.

Overview

The new policy engine provides fine-grained control over tool execution with support for three-tier priority bands (default, user, admin) and sophisticated matching patterns. Users can now customize which tools auto-approve, which require confirmation, and which are blocked entirely.

Key Features

1. Three-Tier Priority System

Default policies (1.xxx): Shipped with the CLI
User policies (2.xxx): User's personal policies
Admin policies (3.xxx): System administrator policies
Higher tiers always override lower tiers

2. TOML Configuration Files

Simple, readable policy definitions in .toml files:

[[rule]]
toolName = "run_shell_command"
commandPrefix = "git status"
decision = "allow"
priority = 100

3. Flexible Matching Syntax

Tool name matching: Exact match or wildcards (my-server__*)
MCP server convenience syntax: mcpName = "google-workspace" expands to all tools from that server
Shell command patterns: commandPrefix for literal matching, commandRegex for regex patterns
Argument patterns: argsPattern for granular tool argument matching
Array expansion: toolName = ["tool1", "tool2"] creates multiple rules

4. Mode-Specific Rules

Apply different policies in different approval modes:

[[rule]]
toolName = "write_file"
decision = "allow"
modes = ["yolo"]  # Only applies in YOLO mode

5. Enhanced Error Handling

Comprehensive validation with helpful error messages:

TOML syntax errors with line numbers
Schema validation errors with field details
Rule validation with fix suggestions
Regex compilation errors with pattern details

Technical Implementation

Architecture

Policy Engine (packages/core/src/policy/policy-engine.ts): Core evaluation logic
TOML Loader (packages/cli/src/config/policy-toml-loader.ts): Dedicated parsing module with error handling
Integration (packages/cli/src/config/policy.ts): Combines TOML policies with settings-based rules
Message Bus Integration: Policies checked via message bus for consistent behavior

Policy File Locations

Default: <install-dir>/packages/cli/dist/src/config/policies/ (shipped)
User: ~/.config/gemini/.gemini/policies/ (user customizations)
Admin: <system-settings-path>/policies/ (admin overrides)

Priority Bands

3.000 - 3.999: Admin policies (highest)
2.950: User "always allow" selections from UI
2.200: Command line --exclude-tools
2.100: Command line --allowed-tools
2.000 - 2.999: User policies
  195: Excluded MCP servers
   90: Trusted MCP servers
   85: Allowed MCP servers
1.000 - 1.999: Default policies (lowest)

Example Policies

Auto-approve safe git commands:

[[rule]]
toolName = "run_shell_command"
commandPrefix = ["git status", "git diff", "git log"]
decision = "allow"
priority = 100

Allow all Google Workspace tools:

[[rule]]
mcpName = "google-workspace"
decision = "allow"
priority = 50

Block dangerous operations:

[[rule]]
toolName = "run_shell_command"
commandRegex = "rm -rf"
decision = "deny"
priority = 200

Changes by Commit

Introduce config-based policy engine - Core policy engine and initial TOML support
Use centralized path utilities - Consistent policy directory resolution
Copy .toml files to dist - Include policies in build output
Add argsPattern support - Granular tool argument matching
Implement priority band system - Three-tier hierarchy with transformation
Fix tool naming - Correct composite naming for MCP tools
Add array syntax support - Expand toolName arrays into multiple rules
Integrate message bus with MCP tools - Policy checks for MCP tools
Add shell command convenience syntax - commandPrefix and commandRegex fields
Move command line flags to user tier - Correct priority for CLI flags
Extract TOML parsing module - Dedicated loader with enhanced error handling

Testing

✅ 13 unit tests for TOML loader (all transformations and error scenarios)
✅ 27 integration tests for policy engine
✅ 12 policy engine integration tests
✅ All existing tests passing (2809 total)

Breaking Changes

None. This is additive functionality that defaults to existing behavior when no policy files are present.

Fixes

Fixes #7837, #7838, #11299, #11300

Documentation

Policy files are auto-discovered from the three locations (default, user, admin) and merged with higher tiers winning. Users can create custom policies by adding .toml files to ~/.config/gemini/.gemini/policies/.

This commit replaces the programmatic policy system with a config-based system using TOML files. This change makes the policy engine more flexible and easier to configure without changing the code. The default policy rules are now defined in TOML files located in the `packages/cli/src/config/policies` directory. The `createPolicyEngineConfig` function has been updated to be asynchronous and now loads these policy files from the disk. The following changes were made: - Added a new `policies` directory in `packages/cli/src/config` to store the default TOML-based policy configurations. - Created `default.toml`, `read-only.toml`, `write.toml`, and `auto-edit.toml` to represent the different policy sets. - Refactored the `createPolicyEngineConfig` function to load, parse, and apply these new TOML configuration files. - Updated all call sites of `createPolicyEngineConfig` to be asynchronous. - Updated all relevant test files to reflect the changes.

Refactored policy directory resolution to use existing utilities instead of hard-coded paths and direct environment variable access. Core changes: - Added Storage.getUserPoliciesDir() method to return ~/.gemini/policies - Provides centralized configuration for user policy directory Policy module changes: - Import Storage from core and getSystemSettingsPath from settings.ts - Replace hard-coded '.gemini' path with Storage.getUserPoliciesDir() - Replace direct process.env access with getSystemSettingsPath() - Remove unnecessary homedir import - Simplify getPolicyDirectories() since getSystemSettingsPath() always returns a value with platform-specific defaults Test improvements: - Update admin policy test to use correct settings.json path format - All 19 policy tests pass Benefits: - Better code reuse and maintainability - Platform-aware path resolution - Single source of truth for policy directory paths

Added .toml extension to the list of file extensions copied during build. This ensures that policy TOML files in src/config/policies/ are included in the dist directory and can be loaded at runtime. Without this fix, the policy engine would fail to load default policy rules from TOML files, causing unexpected confirmation prompts for tools that should be auto-approved (like google_web_search). Fixes issue where google_web_search was asking for confirmation despite being configured as "allow" in read-only.toml.

…hing Added support for regex pattern matching on tool arguments in policy TOML files. This enables fine-grained control over tool approvals based on specific arguments. Changes: - Updated PolicyRuleSchema to accept optional argsPattern field (string) - Convert argsPattern strings to RegExp objects when loading policy files - Added comprehensive test for argsPattern matching with git commands - Proper TypeScript typing for rule conversion - Added debug logging to PolicyEngine.check() and config loading Example use case - allow specific git subcommands without confirmation: ```toml [[rule]] toolName = "ShellToolInvocation" argsPattern = "\"command\":\"git (status|diff|log|branch)" decision = "allow" priority = 100 ``` This allows users to auto-approve safe read-only git commands while still requiring confirmation for write operations like git commit or git push. The pattern matches against the JSON-stringified tool arguments, enabling powerful regex-based filtering. Known issues to address in follow-up PRs: 1. Policy loading only supports specific filenames (read-only.toml, write.toml, etc.) Should scan all .toml files in policies directory 2. Tool name inconsistency: ShellToolInvocation vs run_shell_command constant

Introduces a priority band (tier) system that ensures the policy hierarchy Admin > User > Default is always preserved, while allowing meaningful priorities within each tier. Priority transformation: - Default policies (TOML): 1 + priority/1000 (e.g., 100 → 1.100) - User policies (TOML): 2 + priority/1000 (e.g., 100 → 2.100) - Admin policies (TOML): 3 + priority/1000 (e.g., 100 → 3.100) This prevents high-priority default/user rules from overriding lower-priority admin rules, while maintaining predictable ordering within each tier. Changes: - Add getPolicyTier() to determine directory tier (1=default, 2=user, 3=admin) - Add transformPriority() to apply tier-based transformation - Update createPolicyUpdater() to use user tier priority (2.95) - Simplify policy files by removing unnecessary mode annotations - Reorganize policy files for clarity: - Rename default.toml → yolo.toml - Merge auto-edit.toml into write.toml - Remove redundant "default" mode annotations - Update all tests for transformed priorities - Add comprehensive test coverage for priority bands The modes field is now only used when restricting to specific modes, with rules without modes applying to all modes by default.

Previously, ShellToolInvocation, WriteTodosToolInvocation, and DiscoveredMCPToolInvocation did not pass tool names to BaseToolInvocation, causing the policy engine to see class names (e.g., "ShellToolInvocation") instead of the proper tool names from tool-names.ts constants (e.g., "run_shell_command"). Changes: - Fix ShellToolInvocation to pass _toolName and _toolDisplayName to super() - Fix WriteTodosToolInvocation to pass tool name parameters to super() - Fix DiscoveredMCPToolInvocation to pass composite tool name (serverName__toolName) and messageBus to super() - Add mcpName field to PolicyRuleSchema for TOML policies - Implement mcpName transformation logic: - mcpName only → "serverName__*" (server wildcard) - mcpName + toolName → "serverName__toolName" (specific tool) - toolName only → use as-is (built-in tools or short names) This enables flexible MCP tool configuration: - Server-level: mcpName = "google-workspace" (allows all tools) - Tool-specific: mcpName = "google-workspace", toolName = "gmail.send" - Composite format: toolName = "google-workspace__gmail.send" All tests pass.

Users can now specify multiple tools in a single rule using array syntax: [[rule]] toolName = ["tool1", "tool2", "tool3"] decision = "allow" priority = 100 This also works with mcpName for MCP tools: [[rule]] mcpName = "google-workspace" toolName = ["calendar.findFreeTime", "calendar.getEvent", "calendar.list"] decision = "allow" priority = 100 This is more concise than writing separate rules for each tool and ensures all tools in the array get the same decision and priority. Implementation: - Updated PolicyRuleSchema to accept string or array for toolName - Changed .map() to .flatMap() to expand array entries into multiple rules - Each tool in the array creates a separate PolicyRule with same decision/priority - Added comprehensive test coverage All tests pass (23/23 policy tests, 12/12 integration tests).

This commit fixes the integration between the message bus and MCP tools so that MCP tool invocations properly respect policy rules configured in TOML files. Fixes #7837 Key changes: - Added setMessageBus/getMessageBus methods to ToolRegistry - Set message bus on ToolRegistry before tool discovery (in createToolRegistry) - Updated discoverTools() to accept and pass messageBus parameter to MCP tools - Changed DiscoveredMCPToolInvocation to override getConfirmationDetails() instead of shouldConfirmExecute() to allow policy engine checks - Added debug logging to show when MCP tools are discovered with message bus (guarded by both debug mode and message bus integration being enabled) - Updated test mocks to include getMessageBus method The timing fix was critical: the message bus must be set on the registry BEFORE discoverAllTools() is called, otherwise MCP tools are created without access to the message bus and cannot check policies.

…mands This commit adds convenience syntax for defining shell command policies in TOML files, making it easier to write rules without manually crafting regex patterns. New TOML fields: - commandPrefix: String or array of command prefixes to match (e.g., "git status") - commandRegex: Regex pattern for more complex command matching Features: - commandPrefix automatically escapes regex special characters for literal matching - Array syntax expands to multiple rules (similar to toolName arrays) - Validation ensures these fields only work with toolName = "run_shell_command" - Mutually exclusive with argsPattern (use raw argsPattern for complex cases) Example usage: ```toml [[rule]] toolName = "run_shell_command" commandPrefix = ["git status", "git log", "git diff"] decision = "allow" priority = 100 [[rule]] toolName = "run_shell_command" commandRegex = "git (branch|status).*" decision = "allow" priority = 100 ``` Implementation: - Added escapeRegex() utility to escape regex special characters - Transforms commandPrefix/commandRegex to argsPattern during rule processing - Added validation to prevent misuse (e.g., with wrong toolName) - Added 4 comprehensive tests covering all use cases

This commit moves --allowed-tools and --exclude-tools command line flags from flat priorities (100, 200) to user tier priorities (2.100, 2.200) to align them with the three-tier priority system (Admin > User > Default). Changes: - settings.tools.allowed: 100 → 2.1 (user tier) - settings.tools.exclude: 200 → 2.2 (user tier) Priority hierarchy (highest to lowest): 1. MCP server settings (flat: 85-195) - highest for security 2. Admin TOML policies (3.0-3.999) 3. User TOML policies (2.0-2.999) 4. Command line flags (2.1, 2.2) - now in user tier 5. Default TOML policies (1.0-1.999) This means: - MCP server trust/allow settings override command line flags (by design) - Admin TOML policies override command line flags - Command line flags override default TOML policies - Command line flags have same tier as user TOML policies Updated tests to reflect new priority relationships.

…anced error handling Split sophisticated TOML policy file parsing logic into a separate module to improve code organization and maintainability. This change includes: - Created `policy-toml-loader.ts` with dedicated schemas, validation, and error handling - Comprehensive error types (file_read, toml_parse, schema_validation, rule_validation, regex_compilation) - Detailed error reporting with suggestions for common mistakes - 13 comprehensive unit tests covering all transformations and error scenarios - Refactored `policy.ts` to use the new loader, reducing complexity - Updated integration tests to reflect new user tier priority values (2.1, 2.2) The new loader provides structured error handling with detailed messages, making it easier for users to diagnose and fix policy file issues.

gemini-code-assist · 2025-10-24T21:19:13Z

Summary of Changes

Hello @allenhutchison, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the tool execution policy system by introducing a robust, configuration-driven policy engine. It shifts from hardcoded rules to flexible TOML files, allowing users and administrators to define custom policies with a clear three-tier priority structure. This change provides greater control and transparency over how tools are approved, denied, or require confirmation, making the system more adaptable and secure without breaking existing functionality.

Highlights

Config-Based Policy Engine: Introduced a new, flexible policy engine that allows defining tool execution policies via TOML configuration files, enabling fine-grained control over tool auto-approval, confirmation, and blocking.
Three-Tier Priority System: Implemented a priority system with Default (1.xxx), User (2.xxx), and Admin (3.xxx) tiers, where higher tiers always override lower ones, ensuring a clear hierarchy for policy application.
TOML Configuration: Policies are now defined using simple, readable TOML files, supporting various matching patterns like tool names, MCP servers, shell commands (prefix/regex), and argument patterns.
Enhanced Error Handling: Added comprehensive validation and helpful error messages for TOML syntax, schema validation, rule validation, and regex compilation errors during policy loading.
Message Bus Integration for MCP Tools: Integrated the policy checks with the message bus for MCP (Multi-Cloud Platform) tools, ensuring consistent policy enforcement across different tool types.
Refined Priority Bands: Adjusted priority bands for command-line flags and other dynamic rules to fit within the new tier system, ensuring proper precedence (e.g., --allowed-tools now in user tier 2.100).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

github-actions · 2025-10-24T21:20:53Z

Size Change: +12.6 kB (+0.06%)

Total Size: 20.2 MB

Filename	Size	Change
`./bundle/gemini.js`	20.2 MB	+12.6 kB (+0.06%)

ℹ️ View Unchanged

Filename	Size
`./bundle/sandbox-macos-permissive-closed.sb`	1.03 kB
`./bundle/sandbox-macos-permissive-open.sb`	890 B
`./bundle/sandbox-macos-permissive-proxied.sb`	1.31 kB
`./bundle/sandbox-macos-restrictive-closed.sb`	3.29 kB
`./bundle/sandbox-macos-restrictive-open.sb`	3.36 kB
`./bundle/sandbox-macos-restrictive-proxied.sb`	3.56 kB

_{compressed-size-action}

gemini-code-assist

Code Review

This pull request introduces a powerful and flexible new policy engine based on TOML configuration, which is a significant improvement for managing tool execution policies. The implementation is thorough, covering file loading, parsing, validation, and integration with the existing system. However, there is a critical issue in the new priority system where old, untiered integer-based priorities for MCP settings coexist with the new tiered, float-based priorities. This inconsistency leads to confusing and incorrect precedence evaluation, which could result in unintended tool execution and potential security vulnerabilities. This core issue needs to be resolved by migrating all policy priorities to the new tiered system to ensure predictable and secure behavior.

packages/cli/src/config/policy.ts

packages/cli/src/config/policy-engine.integration.test.ts

Addresses review comments from Gemini Code Assist bot on PR #11992: 1. **Fix inconsistent priority system**: - Move ALL settings-based priorities to user tier (2.x) for consistency - New priority order (highest to lowest): * 2.9: MCP servers excluded (was 195) * 2.4: Command line --exclude-tools (was 2.2) * 2.3: Command line --allowed-tools (was 2.1) * 2.2: MCP servers with trust=true (was 90) * 2.1: MCP servers allowed (was 85) - This fixes the semantic bug where MCP server allow (85) would beat command-line tool exclude (2.2), which was insecure and wrong - Specific tool excludes now correctly beat server-wide allows 2. **Fix AUTO_EDIT mode for write_file**: - Add write_file to autoEdit mode rules in write.toml - AUTO_EDIT now approves both replace and write_file tools - Matches expected behavior from --approval-mode=auto_edit 3. **Update all tests**: - Fix integration test expectations for new priority system - Rename test to reflect correct precedence behavior - Update unit test assertions to use new tiered priorities - Fix test semantics: command line excludes now beat server trust

Fixes 22 failing policy tests on Windows CI by normalizing paths for cross-platform compatibility. **Changes:** - Add nodePath import to both test files - Replace hardcoded Unix-style paths with nodePath.normalize() - Fix path comparisons: - `path === '/policies'` → `nodePath.normalize(path) === nodePath.normalize('/policies')` - `path.includes('.gemini/policies')` → `nodePath.normalize(path).includes(nodePath.normalize('.gemini/policies'))` **Root Cause:** Tests used hardcoded Unix-style paths (`/policies`, `.gemini/policies`) in mocks, but on Windows the loader constructs paths with backslashes using `path.join()`, causing mock comparisons to fail. **Impact:** - All 40 policy tests now pass on both Unix and Windows platforms - policy-toml-loader.test.ts: 13 tests fixed - policy.test.ts: 27 tests fixed

abhipatel12

This looks great! Had a few comment, let me know what you think!

packages/cli/src/config/policy-toml-loader.ts

packages/cli/src/config/policies/read-only.toml

packages/cli/src/config/config.ts

packages/cli/src/config/policy-toml-loader.ts

packages/cli/src/config/policy.ts

packages/core/src/policy/policy-engine.ts

Address PR review feedback to enhance policy configuration UX: - Add priority range validation (0-999) to prevent tier overflow with clear, actionable error messages explaining the tier system - Document priority system in all default TOML files to guide users on proper priority value selection - Implement deferred error reporting so policy validation errors are visible in UI after mount, only when message bus integration is enabled - Gate debug logs on message bus integration to reduce noise when policies are not active - Replace console.error with debugLogger in policy-engine for consistent logging to debug drawer This ensures users see helpful error messages when they misconfigure policies, preventing silent failures and tier boundary violations. Addresses feedback from abhipatel12 in PR #11992

packages/cli/src/config/config.ts

abhipatel12

LGTM! had a comment on the logging but otherwise approved!

packages/core/src/policy/policy-engine.ts

allenhutchison added 11 commits October 24, 2025 14:05

allenhutchison requested a review from a team as a code owner October 24, 2025 21:18

allenhutchison requested a review from abhipatel12 October 24, 2025 21:20

gemini-code-assist bot reviewed Oct 24, 2025

View reviewed changes

packages/cli/src/config/policy.ts Show resolved Hide resolved

packages/cli/src/config/policy-engine.integration.test.ts Outdated Show resolved Hide resolved

allenhutchison added 3 commits October 24, 2025 15:12

Merge branch 'main' into adh/11299-config-based-policy

f97b53b

abhipatel12 reviewed Oct 27, 2025

View reviewed changes

allenhutchison and others added 4 commits October 27, 2025 10:32

Merge branch 'main' into adh/11299-config-based-policy

92081c1

Merge branch 'main' into adh/11299-config-based-policy

b1e05f9

Merge branch 'main' into adh/11299-config-based-policy

8fe83c9

allenhutchison mentioned this pull request Oct 28, 2025

feat(policy): Add validation for tool names in TOML policy files #12119

Closed

6 tasks

Merge branch 'main' into adh/11299-config-based-policy

f12c3d1

abhipatel12 reviewed Oct 28, 2025

View reviewed changes

packages/cli/src/config/config.ts Outdated Show resolved Hide resolved

abhipatel12 approved these changes Oct 28, 2025

View reviewed changes

packages/core/src/policy/policy-engine.ts Outdated Show resolved Hide resolved

allenhutchison mentioned this pull request Oct 28, 2025

Refactor policy toml parsing to core package. #12166

Closed

Moving log statements to debug.

6d8d514

allenhutchison added 2 commits October 28, 2025 09:02

removing a stray comment

5439cde

Merge branch 'main' into adh/11299-config-based-policy

9fa5642

allenhutchison enabled auto-merge October 28, 2025 16:12

allenhutchison added this pull request to the merge queue Oct 28, 2025

Merged via the queue into main with commit 064edc5 Oct 28, 2025
22 checks passed

allenhutchison deleted the adh/11299-config-based-policy branch October 28, 2025 16:30

This was referenced Oct 28, 2025

Enhance PolicyEngine with shell command parsing for granular policies #7838

Closed

Implement config based policy #11299

Closed

Move old programmatic policy to config based policy #11300

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(policy): Introduce config-based policy engine with TOML configuration#11992

feat(policy): Introduce config-based policy engine with TOML configuration#11992
allenhutchison merged 22 commits intomainfrom
adh/11299-config-based-policy

allenhutchison commented Oct 24, 2025

Uh oh!

gemini-code-assist bot commented Oct 24, 2025

Uh oh!

github-actions bot commented Oct 24, 2025 •

edited

Loading

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

Uh oh!

Uh oh!

abhipatel12 left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

abhipatel12 left a comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

allenhutchison commented Oct 24, 2025

Config-Based Policy Engine

Overview

Key Features

1. Three-Tier Priority System

2. TOML Configuration Files

3. Flexible Matching Syntax

4. Mode-Specific Rules

5. Enhanced Error Handling

Technical Implementation

Architecture

Policy File Locations

Priority Bands

Example Policies

Changes by Commit

Testing

Breaking Changes

Fixes

Documentation

Uh oh!

gemini-code-assist bot commented Oct 24, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

github-actions bot commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

abhipatel12 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

abhipatel12 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions bot commented Oct 24, 2025 •

edited

Loading