fix(*): a command the host denies stays denied once it is handed to a sub-agent

[ZuyiZhou]

Summary

A host deny rule bound the host's own tool calls and nothing it dispatched.
The host answered every session/request_permission from an ACP sub-agent
with the most permissive option (raven/acp_client/permissions.py), and a
product launcher rendered its own config without the host's permissions
(Raven-Code pins mode: ask and carries no rules). Measured end to end
before this change: with permissions.tools.exec {"curl *": "deny"} and
tools.exec.extraDenyPatterns ["\\bcurl\\b"] on the host, a curl handed to
Raven-Code asked the host, was answered "Allow for this session", and hit a
loopback sink.

Refusals now travel, on both sides, because a refusal needs nobody to answer:

• Launcher side. product_render.write_rendered merges the host's deny
  entries of permissions.tools and tools.exec.extraDenyPatterns into every
  product render (strictest wins; a product exec tier written as one string
  becomes the * fallback beside the host's patterns; a pattern that does not
  compile is left behind, as the host's own live reader leaves it). Every
  launcher and the scaffold end in that call, and a test pins that. This is
  the half that matters for raven's own products: a call their own gate
  allows never produces a request the host could refuse.

• Host side. The approver reads the command a request names
  (toolCall.rawInput.command, as sent and unquoted, and every codex
  commandActions entry) against the host's builtin deny list with
  extraDenyPatterns and its deny rules, read live, and answers a match
  with the agent's reject option (cancel only when none was offered). A check
  that raises refuses. A parse error is not a refusal. This also covers
  third-party agents, for what they ask about.

• Server side. Raven's own ACP broker now sends a shell call's command as
  rawInput.command (redacted like the title), so a raven host can read it.

• Logs. Both approver log lines (the INFO refusal, and the DEBUG
  approval, which logged the agent's own title) go through the ACP redactor,
  since the command is the sub-agent's to author and the log is retained. The
  redactor moves from raven/acp/redact.py to raven/security/redact.py
  (content unchanged but one docstring paragraph), because raven.acp_client
  may not import raven.acp, and one table beats a second copy.

Deliberately not changed: the ask tier and the mode. What no deny rule names
is still approved, as before; routing the ask tier to the host's human is a
separate decision. A rule added on the host reaches an already running raven
product at its next launch (the host-side check is live, the render is not).
Agents launched with a never-ask setting never send a request, so only their
own configuration binds them. Docs (permissions, protocol backends, both
languages) and the Unattended Approval entry in CONTEXT.md say this.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

Head 703c7ce, rebased onto main 3a463d6 (git range-diff shows both
commits = against the reviewed 4f8e0af; the head is linear again, the two
"Update branch" merge commits are gone). At this head: the six focused suites
480 passed, the e2e 2 passed, git diff --check clean, make lint-imports
10 kept. The full suite was run at the same two commits on earlier bases:
25878 passed / 109 skipped at ca5e5dc15 (shown below), 25881 passed / 110
skipped at 4f8e0af, diff coverage 100% at both. Main's newer commits touch
CONTEXT.md in a different entry and none of the other files here:

uv run pytest -q tests/test_subagent_acp.py tests/test_acp_redact.py tests/test_acp_permissions.py tests/test_acp_server.py tests/test_config_product_render.py tests/test_agents_code_launcher.py
  480 passed
uv run pytest -q -n0 -m integration tests/integration/test_subagent_host_deny_e2e.py
  2 passed   (control run hits the sink; denied run does not, reply names the deny rule)
COLORTERM=truecolor make coverage   (fresh worktree at ca5e5dc15)
  25878 passed, 109 skipped in 619s
COVERAGE_BASE_REF=origin/main make coverage-diff
  Diff coverage: 100.00% (120/120 executable changed lines)
uv run --frozen --python 3.12 --extra dev ruff check raven evolver agents plugins-dist tests scripts   -> All checks passed
uv run --frozen --python 3.12 --extra dev ruff format --check raven evolver agents plugins-dist tests scripts   -> 2084 files already formatted
make lint-imports   -> 10 kept, 0 broken
make lint-deps && make lint-types   -> no issues / All checks passed
git diff --check origin/main...HEAD   -> clean
PYTHONPATH=. uv run --frozen --python 3.12 --extra dev python scripts/check_source_language.py origin/main...HEAD   -> exit 0
make check-commits; make check-pr-title; COMMIT_RANGE=origin/main...HEAD make check-large-files   -> pass

Revert-to-red, one production file at a time restored to origin/main (the
focused suites plus the e2e where it applies; measured on the first commit
before the rebases, which touched none of these files):

reverted	unit	e2e
raven/config/product_render.py	12 failed	1 failed (sink not hit: the host approver refused it, reply "User denied this action"; only the wording assertion fails)
raven/acp_client/permissions.py	2 failed, 14 errors	-
raven/acp/permissions.py	2 failed	-
all three	15 failed, 14 errors	2 errors

The first row is the two halves covering each other: with the launcher half
reverted the host half still stops the command. For the second commit, each
log line's redaction reverted alone turns
test_the_logged_refusal_and_approval_carry_no_credential red (1 failed each).

• Relevant tests pass locally
• Relevant lint / type checks pass locally
• User-facing docs or screenshots are updated when needed

Risk

User-visible: an ACP sub-agent (Raven products, Claude Code, codex) now has a
command refused when it matches the host's deny rules or the builtin
catastrophe list, where it used to run. Hosts with no deny rules see no
difference except the builtin list. Rollback: revert this commit.

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Related Issues

N/A

[gloryfromca]

Blocking: redact the denied command before writing it to retained logs.

I reviewed the PR commit and the surrounding permission gate, ACP dialect/collector paths, live-config readers, product launchers, relevant history, tests, docs, and the repository rules in AGENTS.md, CONTEXT-MAP.md, CONTEXT.md, and agents/README.md. I also checked backward compatibility, the dual enforcement architecture, and that existing tests were not weakened.

Verification on this checkout:

• uv run pytest -q tests/test_config_product_render.py tests/test_agents_code_launcher.py tests/test_subagent_acp.py tests/test_acp_permissions.py: 418 passed, 1 skipped (case-sensitive filesystem)
• uv run pytest -q -n0 -m integration tests/integration/test_subagent_host_deny_e2e.py: 2 passed
• git diff HEAD^..HEAD --check: clean
• Direct log probe: a denied curl command containing a fake Authorization bearer value remained verbatim in the INFO record

The denial behavior itself is well covered and worked in both the unit and end-to-end paths. The inline credential-leak finding is the only blocker I found.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

I reviewed the revision delta and resulting PR diff, including the shared-redactor move, all import callers, the permission paths and product-render enforcement reviewed previously, relevant history, backward compatibility, tests, and the repository architecture/rules in AGENTS.md, CONTEXT-MAP.md, CONTEXT.md, and agents/README.md. No tests were weakened.

The prior credential-log blocker is fixed, replied to, and its thread is resolved. I found no new issue.

Verification:

• uv run pytest -q tests/test_config_product_render.py tests/test_agents_code_launcher.py tests/test_subagent_acp.py tests/test_acp_permissions.py tests/test_acp_redact.py: 449 passed, 1 skipped (case-sensitive filesystem)
• uv run pytest -q -n0 -m integration tests/integration/test_subagent_host_deny_e2e.py: 2 passed
• uv run --frozen --python 3.12 lint-imports: 10 contracts kept, 0 broken
• git diff github/main...HEAD --check: clean

make is not installed in this environment, so I invoked the lint-imports target command directly.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

This head only merges current main into the previously clean revision. I checked the merge delta, the resulting PR file set and diff, the existing resolved thread, and the previously reviewed permission/redaction paths; the feature code and tests are unchanged and no test was weakened.

Verification at 30a99cb3dffc:

• uv run pytest -q tests/test_config_product_render.py tests/test_agents_code_launcher.py tests/test_subagent_acp.py tests/test_acp_permissions.py tests/test_acp_redact.py: 449 passed, 1 skipped (case-sensitive filesystem)
• uv run pytest -q -n0 -m integration tests/integration/test_subagent_host_deny_e2e.py: 2 passed
• git diff --check 215c445a1443...HEAD: clean

The prior credential-log thread remains resolved.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

c5c1083afc53 has the exact same tree (0331f4af966e05adf432a262d9ef635ee95f9536) as the last clean revision 30a99cb3dffc; only the merge commit object changed. I compared the head trees and PR diff, confirmed the prior thread remains resolved, and found no implementation or test change to reassess.

The identical tree was verified in the preceding review with 449 focused tests passed, 1 filesystem-dependent skip, 2 end-to-end tests passed, and a clean diff check.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

This revision rebases the same two reviewed feature commits onto main at 3a463d6cd; GitHub reports the same PR file set, and the new base change is confined to the agent-loop answerless-turn work. I checked the rewritten diff, relevant permission/redaction callers and tests, repository rules/architecture already covered in the substantive review, test integrity, and the resolved thread. No new defect or compatibility change was introduced.

Verification at 703c7ceaff92:

• uv run pytest -q tests/test_config_product_render.py tests/test_agents_code_launcher.py tests/test_subagent_acp.py tests/test_acp_permissions.py tests/test_acp_redact.py: 449 passed, 1 skipped (case-sensitive filesystem)
• uv run pytest -q -n0 -m integration tests/integration/test_subagent_host_deny_e2e.py: 2 passed
• git diff --check 3a463d6cd252...HEAD: clean

The prior credential-log thread remains resolved.

[LivXue]

No blockers in the reviewed scope.

Scope: my review covers the raven/agent/** portion of this PR, which is 0 of the 22
changed files. Nothing here can carry an inline note, so the three observations below are
disclosed in this summary instead. I read the whole diff as context to reach them. Note
that this PR changes sub-agent permission behaviour without touching raven/agent/ at
all, because the ACP client sits outside that package.

I examined: the outbound approver and its command extraction, the broker change that puts
rawInput.command on the wire, inherit_host_denials and the write_rendered chokepoint,
the rule engine it merges into (permissions/rules.py, permissions/builtin.py), the live
config readers, the three ACP dialects, the layering contracts, and the existing review
round on this PR.

Observations, none of them blocking:

1. inherit_host_denials applies its pattern-table merge to every tool in
   permissions.tools, but a pattern table is only meaningful for exec. For any other
   tool the merge rewrites the product's string tier into a dict, and user_tier returns
   None for a dict entry on a non-exec tool, so the product's explicit rule is dropped
   and the call falls to that tool's default tier. For the tools in DEFAULT_ALLOW_TOOLS
   that turns an explicit ask into allow, which is a loosening produced by a change
   whose purpose is to tighten. Reproduced end to end through write_rendered: host
   {"permissions": {"tools": {"message": {"spam *": "deny"}}}} (which validates against
   PermissionsConfig) plus product {"message": "ask"} renders
   {"message": {"*": "ask", "spam *": "deny"}}, where user_tier returns None and
   default_tier("message") is allow. Likelihood is low, since a dict entry on a
   non-exec tool is already inert on the host itself, so an operator writing one has
   written dead config either way. Worth narrowing the loop so a non-exec tool only takes
   the whole-tool deny branch.

2. The on-the-wire redaction runs before the deny check, so an extraDenyPatterns entry
   that targets credential-shaped text cannot match on the raven-to-raven path. With
   extraDenyPatterns: ["AKIA[A-Z0-9]{16}"], host_refusal refuses
   aws configure set aws_access_key_id AKIAIOSFODNN7EXAMPLE and returns None for the
   [redacted] form the broker actually sends, which is then approved. Reproduced against
   both forms. This is a tension rather than an oversight: the command is going to a client
   that may be an editor which renders and persists it, so sending it unredacted has its own
   cost, and raven's own products have a second line of defence because
   inherit_host_denials already baked the same patterns into their config. The gap is the
   sub-agent whose config the host does not render, which is the case this client-side check
   exists for. Flagging it as a decision rather than a defect.

   To be clear about what this is not: it is a different redaction point from the log leak
   already fixed and resolved in this PR. That one was the retained log line in
   acp_client/permissions.py (second commit); this one is rawInput.command in
   acp/permissions.py, which arrived in the first commit.

3. Where requested_commands cannot read a command, host_refusal returns None and the
   request is approved. A list-valued rawInput.command takes that path even when a deny
   rule covers the command: reproduced, a host denying curl * answers allow_always to
   {"command": ["curl", "-s", "x"]}. No adapter is known to send that shape today, and the
   base dialect reads a string too, so this is not a regression -- but the deny check
   inherits the extraction blind spots of a display path, where a miss costs a label and
   here costs the refusal. The failure direction may be worth stating deliberately.

Verification:

• pytest tests/test_config_product_render.py tests/test_subagent_acp.py tests/test_acp_permissions.py tests/test_acp_redact.py tests/test_agents_code_launcher.py
  at this head: 449 passed, 1 skipped (case-sensitive filesystem).
• lint-imports at this head: 10 contracts kept, 0 broken. The move of redact.py to
  raven.security is what makes the acp_client import legal under
  "inner layers know no surface", so the move is load-bearing rather than tidying.
• Observations 1, 2 and 3 were each reproduced by running the shipped functions, as
  described above. I did not run the integration test or the full suite; the author and the
  previous reviewer both report those green.

Checked and deliberately not reported:

• "A refusal always wins" holds for exec: a product blanket allow with a host
  git push * deny resolves to deny, a product git * allow against a host git push *
  deny resolves to deny (strictest among specific matches), and a host whole-tool deny
  replaces the product table. Verified by running all three.
• The lru_cache on _host_policy is safe. LiveConfig.raw() re-reads by content and
  resolves its path per read, and BuiltinRulings._refresh_deny_patterns runs before every
  classification, so the docstring's claim that an operator's edit binds the next request
  holds.
• test_every_launcher_writes_its_render_through_write_rendered globs agents/*/run.py
  rather than listing launchers, so a new product is covered automatically.
• host_config() reads raw JSON without schema validation. Both directions fail safe: an
  invalid tier simply does not match deny and carries nothing, and a host config that
  fails validation still carries its raw deny entries, leaving the product stricter than
  the host rather than looser.
• The 16 KiB evidence clamp in permissions/gate.py truncates a command before it reaches
  rawInput.command, which could in principle drop a tail a deny pattern would match. A
  shell command that long is rare enough not to report.
• requested_commands duplicating the dialects' permission_command() is deliberate and
  documented (it takes every parsed segment, not the first). Both current dialect shapes are
  covered; only a future dialect reading a new field would diverge, in the same direction as
  observation 3.
• The credential-in-log finding from the previous round is already fixed and resolved. I did
  not re-file it.