CLI v3: "Always allow" for "pattern · session" is not working

[thraciatron]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

Windows 11

Kiro Version

2.8

Bug Description

When the default agent asks for approval to run a command, if you select "Always allow" and then select "pattern · session" trust level, it just refreshes and asks you again, and again until you select "Allow".

Example of command

 Run Command requires approval
 shell → cd c:\Users\username\project && dir test\*.ts /s /b

   Allow
❯  Always allow
   Deny
   Always deny
....
   Trust "cd c:\Users\username\project && d…"    exact match · session
 ❯ Trust "cd *"                                                pattern · session
   Trust entire tool (Run Command)                             session

Cycling through (s) to workspace, session or always produces the same result.

Steps to Reproduce

1. Open Kiro kiro-cli --v3
2. Tell it to create tests for some code
3. Even though you are in the project directory it decides to run a "cd" command and wants permission
4. Select "Always allow" and the select "Trust pattern · session"
5. Notice the CLI refreshes and asks you again

Expected Behavior

Once the pattern is trusted, I should not be asked again for the workspace, session or always depending on whats selected.

Conversation ID

No response

Additional Context

No response

[github-actions]

🤖 Potential Duplicate Detected

This issue appears to be similar to:

• #9453: MCP autoApprove duplicates permissions and repeatedly prompts for the same approval (85% similar)
• #7133: execute_bash got full trust permissions from another tool approval (85% similar)

What happens next?

• ⏰ This issue will be automatically closed in 3 days
• 🏷️ If this is not a duplicate, you can prevent automatic closure by adding a comment or reacting with 👎 to this message.
• 💬 Comment on the original issue if you have additional information

Why is this marked as duplicate?
Both issues report problems with approval/permission systems where 'always allow' or 'autoApprove' settings don't work properly and repeatedly prompt for the same approval, despite different contexts (CLI v3 vs MCP)

[github-actions]

Thank you for your feedback! 🙏

The 👎 reaction has been noted. The duplicate label has been removed and this issue has been sent back for maintainer review.

A maintainer will review this issue shortly.

[koa-leo]

The latest version of the client also has the same problem.

[debikurnia]

Reproduces on macOS too — root cause is a literal backslash in the command (not Windows-specific)

Same loop on macOS, Kiro CLI 2.9.0 (agent engine v3, @kiro/agent 0.3.299). The common factor between this report and mine is a literal backslash in the command:

• This issue (Windows): cd c:\Users\username\project && dir test\*.ts /s /b
• Mine (macOS): python3 -c "import sys,json; ...; print('\n'.join(...))"

Both contain \. Any backslash-containing shell command loops; the same command without a backslash (ls -la, php artisan test) persists with one Always allow and never re-prompts. Workaround confirmed: Allow (once) runs it without the loop.

Almost certainly the same root cause as the closed-as-duplicate #9562 (execute_pwsh on Windows, identical "Permission flow exceeded 20 approval rounds" error). #9620 looks related but distinct — there the allow-rules seem ignored entirely, not a backslash-specific loop.

Evidence

~/.kiro/logs/<ts>/kiro.log — the same operationId re-prompted 11×, and the rule was persisted 6× while still re-prompting:

[ACP ToolApproval] Requesting permission ... operationId=run_command_tooluse_0cJtdQBIyVv1jw7CoSobyC   (x11)
[PolicySession] Persisted allow rule for shell matching "python3 -c \"... print('\n'.join(...)) \""    (x6)

In the same session, every shell command without a backslash persisted once and never looped.

Root cause

src/policy/cedar-compiler.ts → globToCedarLike() rewrites \ → / for every capability:

result = result.replace(/\\/g, '/');   // path normalization applied to ALL capabilities

So a persisted shell rule match: ["... '\n' ..."] compiles to a Cedar like pattern containing '/n'.

The resource side is not normalized — src/policy/policy-engine.ts → evaluateSingle() passes the raw command (resource.path = resourceId, backslash preserved). Cedar then tests resource.path like "...'/n'..." against resource.path = "...'\n'..." → / ≠ \ → no permit fires → falls through to the default ask.

That feeds the bounded re-evaluation loop in src/acp/acp-tool-approval.ts (createAcpToolApproval → onAsk, MAX_ITERATIONS = 20): every always-accept persists the rule, rebuilds the policy, re-evaluates → ask again → re-prompts, until it fails with "Permission flow exceeded 20 approval rounds." Shell commands are split into sub-commands matched as resource: cmd, so Windows paths hit it on every \ separator.

Filesystem rules are unaffected because fs_read/fs_write match a canonicalized, already-forward-slashed resource.path, so \ → / is correct there. It is only wrong for non-path capabilities: shell, mcp, subagent, web_fetch, skill/steering ids. This looks adjacent to the 2.9.0 fix for compound shell-command loops — same loop, different trigger.

Suggested fix — make the backslash transform capability-aware

--- a/src/policy/cedar-compiler.ts
+++ b/src/policy/cedar-compiler.ts
@@
-import { expandCapability, getEffectiveCapability } from './capabilities.js';
+import { expandCapability, getEffectiveCapability, FILESYSTEM_CAPABILITIES } from './capabilities.js';
+import type { Capability } from './types.js';
@@ export function compileToCedar(...)
-      for (const conditions of buildConditionVariants(rule)) {
+      for (const conditions of buildConditionVariants(rule, capability)) {
@@
-function buildConditionVariants(rule: PolicyRule): string[] {
+function buildConditionVariants(rule: PolicyRule, capability: string): string[] {
@@
   const matchConditions: Array<string | undefined> = matchAll
     ? [undefined]
-    : rule.match.flatMap((p) => matchConditionsForPattern(p));
+    : rule.match.flatMap((p) => matchConditionsForPattern(p, capability));
@@
-function matchConditionsForPattern(pattern: string): string[] {
-  const likeCond = `resource.path like "${globToCedarLike(pattern)}"`;
+function matchConditionsForPattern(pattern: string, capability: string): string[] {
+  const likeCond = `resource.path like "${globToCedarLike(pattern, capability)}"`;
@@
-function globToCedarLike(pattern: string): string {
+function globToCedarLike(pattern: string, capability: string): string {
   let result = pattern;
   result = result.replace(/\*\*/g, '*');
-  // Normalize to forward slashes for cross-platform matching
-  result = result.replace(/\\/g, '/');
+  // Backslash handling is capability-dependent. Filesystem caps match a
+  // canonicalized, forward-slashed resource.path, so `\` -> `/`. Non-fs caps
+  // (shell, mcp, subagent, web_fetch, ...) match the RAW resource string where
+  // `\` is a literal byte; rewriting it to `/` makes a persisted rule never
+  // match its own resource (e.g. a shell command with `'\n'` or a Windows
+  // path), spinning the consent re-eval loop to MAX_ITERATIONS. Escape it for
+  // the Cedar string literal instead.
+  if (FILESYSTEM_CAPABILITIES.includes(capability as Capability)) {
+    result = result.replace(/\\/g, '/');
+  } else {
+    result = result.replace(/\\/g, '\\\\');
+  }
   result = result.replace(/"/g, '\\"');
   return result;
 }

(The bare-prefix == branch already uses cedarEscape(), which escapes \ → \\, so it stays consistent.)

Regression test

Persist { capability: 'shell', effect: 'allow', match: ["printf 'a\\nb'"] }, evaluate printf 'a\nb', expect allow (currently ask → loops). Add a Windows-path case (type C:\Users\x) and an mcp/web_fetch resource containing \.

Workaround until fixed

Use the stable v2 engine (kiro-cli chat without --v3), author the rule with a wildcard that avoids the backslash (e.g. match: ['python3 -c *']), or click Allow (once) instead of Always allow.