[Bug] deny wildcard "*" overrides preceding allow rules in --prompt mode

[arch7tect]

Summary

According to the Configuration files docs, permission rules are "matched in order — the first matching rule takes effect."

However, in kimi --prompt (headless) mode, a catch-all deny rule with pattern "*" placed after explicit allow rules appears to override the earlier allow rules, causing allowed tools to be rejected.

Reproduction

Create an ephemeral KIMI_CODE_HOME with this config.toml:

[[permission.rules]]
decision = "allow"
scope = "user"
pattern = "Read"

[[permission.rules]]
decision = "allow"
scope = "user"
pattern = "Grep"

[[permission.rules]]
decision = "allow"
scope = "user"
pattern = "Glob"

[[permission.rules]]
decision = "deny"
scope = "user"
pattern = "*"

Run:

export KIMI_CODE_HOME=/path/to/that/home
kimi --prompt "Read README.md and summarize it in one sentence." --output-format text

Expected behavior

Read should be permitted because the first matching rule is allow Read.

Actual behavior

Read is denied with reason "Blocked by the read-only consultation wrapper" (the deny * rule).

Additional observations

• Configuring only allow Read works.
• Configuring allow Read followed by deny Bash works and correctly blocks only Bash.
• Configuring allow Read/Grep/Glob followed by deny "*" blocks Read.

Environment

• Kimi Code CLI version: 0.27.0
• OS: macOS
• Shell: bash

Impact

This makes the documented "allow specific tools, then deny all" pattern unusable for headless wrappers that want to restrict Kimi to a read-only toolset.

[arch7tect]

Update: reproduced under the default shell as well.\n\n- Default login shell: /bin/zsh (macOS).\n- The same ephemeral config (allow Read/Grep/Glob followed by deny "*") blocks Read when the reproduction is run from zsh.\n\nSo this is not bash-specific.

[hogeheer499-commits]

I traced this on current main before proposing a fix. There is a contract mismatch:

• docs/en/configuration/config-files.md says rules are evaluated in order and the first matching rule takes effect.
• packages/agent-core/src/agent/permission/policies/user-configured-rules.ts evaluates rules through separate decision policies, and the policy chain intentionally runs user-configured-deny before ask and allow.
• Existing permission tests explicitly assert that deny/ask decisions take precedence over matching allows.

Could a maintainer confirm which behavior is intended? If ordered first-match semantics are the contract, I can submit a focused implementation plus regression coverage for the allow-before-deny case. If deny-first precedence is intentional, the safer fix appears to be correcting the configuration documentation instead.