feat: let raven read and change its own configuration

[arelchan]

Summary

Raven can now read and change its own configuration through one tool, raven_config, instead of telling the user to open Settings or editing config.json with file tools. The same path lets it connect preset sub-agents and diagnose the ones that do not answer, and asks the user only for what needs them (a key, a sign-in, a paid model).

The tool and its catalog

• raven_config actions: describe (every setting with its value, or a search), get, set (one path, or several under one confirmation), unset, add (connect presets, several at once), test, restart (reload or restart once pending changes are gathered). session.model switches only the current conversation.
• raven/config/self_surface.py is the catalog: 14 sections, about 93 settings, each with its value kind, its writer, and when a change takes effect (next turn, at once, reload, restart, memory server, or inert). Writes go through the RPC methods the settings page already uses (SELF_CONFIG_METHODS allowlist), so the page and the agent share one validation path. tests/test_config_self_surface.py holds every entry against the schema and every next-turn claim against a real reader.
• A refused sub-agent comes back with one next step per refusal kind (9 Raven fixes itself, 5 the user does), with stop rules: no hunting for keys, no credential stores, no restarting another app's services, stop after three commands that explain nothing.
• subagents.add stays preset-only: every execution field comes from the preset. Presets can be named by display name, an add can pin a model the agent lists, and a model pick on an unmeasured agent reads the handshake menu first.
• The companion skill raven-self-config describes the whole flow; its description is injected every turn, the body is read on demand.

Approval

• Reads run unasked. Every write asks by default, on a dedicated config card (what changes, before and after, when it takes effect, a sensitive note). A grant for the session never carries a change.
• In a turn someone is at, full access, the user's allow rule, and smart mode's reviewer let a change through; the reviewer never approves a sensitive setting. Sensitivity is declared by the owner: catalog entries (approval mode and review model, workspace confinement, sandbox, deny patterns, disabled tools, MCP servers switched on, skill blocklist and auto-install, provider endpoints, web and media proxies, remote machines, workspace path, lent keys, sub-agent descriptions) and each channel adapter's spec (who may instruct Raven, whether a channel is on, where its credentials and traffic go, encryption). The gate and the tool read a call the same way: one value decoder, one path spelling, one channel field lookup, an object value judged field by field; a path the tool does not write is refused at the gate, and a call naming one setting twice is refused. A value is secret when the schema, the channel spec or the catalog says so, a credential-named env entry, any header, or a credential inside a URL. The reviewer's instruction counts the agent's own non-security settings as ordinary work. Unattended turns (cron and other scheduled runs, no one to answer) are refused; a channel user who can answer an approval is attended.

Secrets

• A key never travels through a tool call. The agent names the secret with an empty value and a credential card of its own (credential.request / submit / skip / pending / closed) takes it; the host writes it through the handler that owns it and the model learns only saved or skipped. Channel secrets use the same card. A call that only asks for keys goes straight to the card. Enabled on page surfaces only.
• Tool output is scrubbed of the values Raven holds (config/held_secrets.py, including JSON-escaped spellings and URL credentials) and dotfile reads under home are redacted, once, inside ToolRegistry.execute, so the trace span, the page's diffs, the sentinel and both agent loops get the scrubbed copy. What a sub-agent says is scrubbed where it is kept: transcripts, call labels, closing text, the output a later DAG node renders, error records, announces, the ACP frame journal, probe details. A key pasted into the chat is refused.
• Lent keys: an ACP sub-agent row can name Raven providers (lendKeys) whose key it is started with. The row stores the provider name; each start (the spawn path and the capability probe) reads the key into the variable the preset reads (presets.LENDABLE_KEYS, Pi only for now), so it never reaches the model and follows a rotated key. Verified live: Pi refused without it, answered with Raven's OpenRouter key, and its row reads connected and tested with a 398-model menu.

Page

• Config card and credential card; the model and permission chips refresh after the agent changes them; the transcript names raven_config calls by what they did.
• Agents page: the note on a refused connect, a failed test, or a check that found a problem offers "Hand it to Raven" on its title line; it opens a new conversation with a prompt naming the agent and the reason, not sent. A connected row whose check found a problem now shows one head line and an amber note in the body (shaped like a failure's) instead of the check's English sentence folded under the head.

Other

• Memory LLM left unset follows the main model (EverOS restarts when the main model moves).
• Reload and restart wait for page turns in flight too.
• plugin points agents and chat apps at raven_config; cron names the missing message; a GNU timeout shim on hosts without one, accepting only the durations the permission gate parses (one shared definition); read-only package-manager subcommands allow.
• Contracts: CONTRACTS_VERSION 35 (this branch's credential types plus main's FileWrite) with the surface repinned; paper-tier line ceiling 3,700 (measured 3,682) with its review note. CONTEXT.md defines the self-configuration surface and lent key.

Type

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

Verification

• uv run pytest -q -n auto: 27187 passed, 3 failed. The 3 fail on this machine regardless of this branch: test_rpc_files::test_a_host_without_libreoffice_says_so (LibreOffice is installed here), test_simulation_scenario::test_a_fresh_trial_refreshes_the_subagent_homes_before_it_runs and test_simulation_suite::test_a_stopped_run_is_marked_in_its_record_and_finished_with_its_evidence. schemas/subagent.schema.json is regenerated for lendKeys; test_import_cycle_budget holds (the capability probe takes the launch env from its caller rather than importing the agent layer).

• make lint-ui (gen:check, eslint, tsc): pass; the 4 eslint warnings are in files this branch does not touch.

• npx vitest run in ui-web: 3116 passed; check-css, check-class-namespace, check-page OK.

• npm run lint:i18n, lint:rpc, type-check in ui-tui: pass.

• uv run ruff check and ruff format --check on every changed Python file, and lint-imports (10 contracts kept): pass.

• In a browser against a local gateway: credential card save, skip, replace and reload replay; the value appears in no session, trace or log. Agents page link opens a new task with the prompt filled and unsent; sent, the agent reads the self-config skill and calls raven_config first, and for Pi offers Raven's key before a sign-in.

• Smart-mode reviewer, run against the real model: 7 ordinary config changes allowed; sed or write_file on Raven's config, reading an SSH key, and curl | sh escalated.

• Relevant tests pass locally

• Relevant lint / type checks pass locally

• User-facing docs or screenshots are updated when needed

Risk

• Behaviour changes: the agent can now change settings and connect sub-agents after the user confirms (or unasked under full access, and under smart mode for non-sensitive settings). Lending gives a sub-agent Raven's key for a provider after an explicit, sensitive confirmation; what it spends is billed to that key.

• Memory: a memory LLM left unset now follows the main model, so long-term memory starts working after the upgrade for anyone who never pinned one, extracting on the main model and billed to the main provider's key, and EverOS restarts when the main model changes. To keep it off, set memory.backend to null; to keep it on a different model, pin one of its own.

• Backward compatible: new config fields are optional, and both probe fingerprints include lendKeys only when set, so recorded verdicts and menus survive. A config.json written with lendKeys will not load on an older build (extra=forbid).

• Rollback: revert this PR; nothing is migrated. To switch the feature off without a revert, add raven_config to tools.disabledTools.

• Security impact considered

• Backward compatibility considered

• Rollback path is clear for risky changes

Related Issues

N/A

[gloryfromca]

Blocking: sensitive configuration changes can bypass confirmation, secrets still leak through result telemetry, and the new timeout test fails on Linux.

I reviewed the complete github/main...HEAD diff and the surrounding callers/history. I covered the repository rules and canonical terms in AGENTS.md, CLAUDE.md, CONTEXT-MAP.md, CONTEXT.md, ui-web/CONTEXT.md, and the shipped-agent contract; the configuration catalog/write path; permission and credential flows; sub-agent key lending/probes; RPC and reload lifecycle; Web UI consumers; backward compatibility; and whether tests were weakened. I tried to refute each item against its call path and kept only the three concrete failures marked inline.

Verification after uv sync --all-packages:

• uv run pytest -q -n 0 over the 15 directly affected Python test modules: 1,493 passed, 96 skipped, 1 failed. The failure is the inline timeout -s KILL case and is also the current Ubuntu CI failure.
• Selected affected Web UI tests: 392 passed across 6 files.
• git diff --check github/main...HEAD: pass.

[gloryfromca]

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

Reviewed the 0abda68 delta against the previously reviewed full main diff and verified all three prior blockers: lending adds cannot reach the smart reviewer, secret-bearing tool output is scrubbed before every log/UI/model consumer, and the compatibility test now measures the generated timeout shim with GNU-compatible SIGKILL status. No tests were weakened.

Verification: uv run pytest -q -n 0 tests/test_raven_config_tool.py tests/test_agent_loop_run_emit.py tests/test_security_untrusted_context.py tests/test_sandbox_compat_bin.py -> 166 passed. Current CI has one red unit shard: all 6,673 tests in that shard passed, but the session failed its idle-time watchdog on an untouched DAG test; the other completed checks pass.

Coverage included AGENTS.md and the domain context, the revision delta, affected callers and execution ordering, relevant history, backward compatibility, test-strength changes, and the permission/security architecture.

[gloryfromca]

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

The new revision only adds coverage for existing fallback paths. I checked the added cases against the credential broker, credential RPC registration, sub-agent capability/model fallback, held-secret cache, dotfile redaction, and lent-key readers; they preserve the intended behavior and do not weaken prior assertions.

Verification: uv run pytest -q -n 0 tests/test_rpc_credential_broker.py tests/test_rpc_subagents.py tests/test_security_untrusted_context.py -> 162 passed. Completed CI checks are green; three unit shards were still running when reviewed.

Coverage included AGENTS.md/CLAUDE.md and runtime context rules, the delta against the previously reviewed full diff, affected callers and history, backward compatibility, test strength, and architecture boundaries. No production behavior or architecture changed.

[gloryfromca]

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

This revision only replaces an irrelevant real EverOS backend dependency in three DAG memory-record tests with the existing lifecycle fake. The tests still exercise their intended cancellation, file-writing, and instance-propagation behavior, so this removes external latency without weakening the assertions or changing production behavior.

Verification: uv run pytest -q -n 0 tests/test_subagent_dag_runner.py -> 270 passed. Completed CI checks are green; three unit shards were still running when reviewed.

Coverage included AGENTS.md/CLAUDE.md and runtime context rules, the delta against the previously reviewed full diff, the memory backend caller and test history, backward compatibility, test strength, and architecture boundaries.

[gloryfromca]

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

The new revision merges current main. I reviewed the current github/main...HEAD diff against the previously reviewed feature and checked the overlapping approval-sheet files and merge history. The resolution preserves main's Escape/Cmd+Enter/Shift+Cmd+Enter behavior while keeping self-configuration approval one-time-only: its broader chord is consumed without granting anything, and its ordinary allow chord still answers. Existing tests pin both behaviors, with no weakened assertions.

Verification: npm test -- --run src/features/composer/approve.test.ts -> 49 passed; npm test -- --run scripts/gates/approval-card-css.test.mjs -> 4 passed; npm run type-check -> passed. A preliminary direct node invocation of the Vitest gate was invalid because it bypassed the Vitest runner; the same gate passed through the project test command. Completed CI checks are green; four unit shards were still running when reviewed.

Coverage included AGENTS.md/CLAUDE.md and the UI/runtime context rules, the current diff, overlapping callers and merge history, backward compatibility, test strength, and architecture boundaries.

[gloryfromca]

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

Reviewed the new merge revision against both the previously reviewed head and current main. The three manual conflict resolutions correctly retain both branches' contract additions: contract version 35, both FileWrite and credential exports in the ledger, and the cumulative 3,700-line paper-tier ceiling (3,682 measured). I found no weakened tests or compatibility regression.

Verification: uv run pytest -q -n 0 tests/test_contracts_two_tier_ledger.py tests/test_kernel_budget.py tests/test_agent_loop_run_emit.py tests/test_shell_command_writes.py tests/test_raven_config_tool.py passed (182 tests), and git diff --check passed for both the revision delta and the full PR diff. CI has one red shard on the untouched ACP heartbeat timing test (1 failed, 6,920 passed); that case passed 10/10 locally, neither merged delta changes its ACP code or test, and the merged main commit passed all four unit shards, so I do not attribute that failure to this revision.

Coverage included AGENTS.md, CLAUDE.md and applicable CONTEXT guidance, the diff and conflict resolutions, callers and history, backward compatibility, test-strength review, and the contract-tier architecture constraints. All three threads I opened remain resolved.

[0xKT]

Not a blocker, but it is the same seam as the sub-agent scrub thread and worth fixing in the same pass: inside add_tool_result itself, the scrub covers one of two branches.

context/builder.py:292-297:

result = scrub_held_secrets(result)
if blocks:
    content = wrap_untrusted_blocks(blocks, source=tool_name)
else:
    content = wrap_untrusted(result, source=tool_name)

When blocks is present the scrubbed result is discarded and the model message is built from blocks, which nothing scrubbed. wrap_untrusted_blocks fences text blocks but does not scrub them. The same asymmetry is upstream: turn_path.py:1394 scrubs model_text, while turn_path.py:1452 takes result_blocks raw and organ_glue.py:99 passes them through untouched when the model can carry an image in a tool role. redact_home_config_read rides on the same call, so it is bypassed there too.

Reproduced, with the no-blocks arm as the control:

ARM A (no blocks) secret present in model message: False
ARM B (blocks)    secret present in model message: True
CONTROL the scrubber works on this value: True
CONTROL arm B is the branch that drops `result`: True

I am filing this as not blocking because of reachability, and I would rather say so than overstate it. Blocks are set only for a multimodal result on a model that carries images in a tool role, and the producers are mcp/resources.py:309 (blocks=[text_block(text), *blocks], where the text block carries the whole resource text), mcp/client.py:101, browser.py:386 (a page summary beside a screenshot) and filesystem.py:219 (an image description). So it takes an image-bearing tool result whose text half contains one of Raven's own keys. That is real but it is not the jq config.json case the module was written for, which goes through exec, returns a plain string, and is scrubbed correctly.

Scrubbing the text blocks where they are fenced would cover both branches from one call.

[gloryfromca]

Blocking: resolve the newly reported self-configuration security gaps before merging.

The head is unchanged, but the new review record invalidates my earlier clean stance. I traced all five reports and reproduced the relevant production predicates:

• The three outbound-destination settings are not sensitive, so smart mode can approve changes that redirect credential-bearing traffic.
• The raven-loop subagent path fences raw tool output but never applies the held-secret scrub before sending it to its model.
• With curl *: deny and *: allow, direct curl and timeout 0.5 curl ... deny, while the installed shim accepts .5, 1e3, and +5 spellings that the gate classifies as allow.
• A trailing space bypasses both sensitive and secret classification before the tool normalizes the path; this preserves the sensitive-setting write bypass and exposes supplied secret text in approval rendering.
• Feishu encrypt_key is secret in the adapter schema, but channels.feishu.encryptKey is not secret to the gate and its plaintext is rendered in the approval text. The downstream channel writer does discard that supplied value and route to the credential flow, so persistence is prevented, but that happens after the exposure and does not defeat the reported control gap.

I did not reply in or resolve another reviewer's threads. Their blockers remain open for the author to address. Verification: uv run pytest -q -n 0 tests/test_config_self_surface.py tests/test_permissions_gate.py tests/test_raven_config_tool.py tests/test_security_untrusted_context.py tests/test_sandbox_compat_bin.py tests/test_shell_policy_reasons.py passed (500 tests); those passing tests do not exercise the reported bypass cases.

[arelchan]

On the blocks branch of add_tool_result (no thread for this one): fixed in bbbe84b. The text blocks of an image-bearing result are scrubbed at the source in turn_path (held keys plus redact_home_config_read, through the shared scrub_tool_blocks) and again in add_tool_result before they are fenced. Pinned by test_a_held_key_in_an_image_bearing_result_never_reaches_the_model and test_a_dotfile_read_with_pictures_is_redacted_in_its_text_blocks.

🤖 Addressed by Claude Code

[gloryfromca]

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

Verified the revision delta from the previously reviewed head and the full PR context. The five security blockers are addressed at their shared enforcement points: keyed-traffic destinations are sensitive, permission and execution share canonical paths, channel secrecy comes from adapter specs (including object writes), both agent loops and multimodal text blocks use the shared output scrubber, and the timeout shim accepts only the duration grammar the gate can unwrap. The earlier nonblocking image-block seam is covered by the same scrub fix. I found no weakened tests or compatibility regression.

Verification: the focused config, permission, shell-policy, agent-loop and secret-output suite passed (610 passed); i18n boundary, prompt and source-language tests passed (49 passed). The local TUI generator check could not start because this worktree lacks the prettier Node dependency, while CI's TUI check and all four unit shards passed; the aggregate coverage job was still running at review time. git diff --check passed for both the revision delta and full PR diff.

Coverage included AGENTS.md/CLAUDE.md and applicable CONTEXT guidance, the delta and full diff, the merge-only i18n conflicts, callers and history, backward compatibility, whether tests were weakened, and the permission/configuration architecture constraints.

[0xKT]

Not a blocker, and separate from the three threads -- one more catalog entry

Severity of this one finding, not a verdict on the pull request. The blocking findings from this pass are review threads on the changed files; GitHub renders those collapsed, as a file name with no text.
in the same family as the proxy/endpoint ones you just marked.

permissions.judgeModel names the model that decides whether a smart-mode call
is allowed, and it carries no sensitive=. Its sibling two entries up does:

permissions.mode        sensitive='full' runs every tool call without asking
permissions.judgeModel  (none)

So a raven_config set permissions.judgeModel ... is offered to the smart-mode
reviewer rather than to the user, which means the reviewer can approve its own
replacement.

Not blocking, for two reasons I checked rather than assumed: the value is a model
name, not an endpoint (providers.*.apiBase is the endpoint, and you have now
marked it), so the attacker must name a model an already-configured provider
serves; and a name that resolves to nothing makes the judge fail, which
gate.py answers by escalating rather than by allowing. It degrades the reviewer
instead of defeating it.

Mentioning it because the three threads are about the same question -- which
settings a reviewer may settle on the user's behalf -- and this is the cheapest
of the four to close.

[gloryfromca]

Blocking: the three newly opened security-control gaps must be resolved before this revision merges.

The head is unchanged, but the new open threads invalidate my earlier clean stance. Static inspection confirms the cited source conditions: canonical_path() leaves a space when the input ends in space-plus-dot; provider secret classification does not consult ProviderConfig declarations such as extra_headers; and channel destination fields are not catalogued as sensitive even though the smart-mode gate uses that flag to keep them with the user. These are @0xKT's findings, so I am not re-grading, replying in, or resolving their threads. No tests were rerun because this answer evaluates new comments on unchanged code; the prior verification remains the latest test result for this head.

[arelchan]

On permissions.judgeModel (no thread): fixed in e193368, it is now sensitive (it picks the reviewer that settles smart-mode calls), added to test_a_setting_that_redirects_keyed_traffic_stays_with_the_user.

🤖 Addressed by Claude Code

[gloryfromca]

Blocking: the three open security findings need their author or a maintainer to settle them before this revision merges.

I independently verified that this head closes the paths they cite: canonical_path() now removes whitespace and dots as one character set; provider-level extraHeaders and Gemini apiKeyList follow the provider writer's secret classification into held-secret scrubbing; adapter-declared channel destinations and permissions.judgeModel stay out of smart-mode review. These are @0xKT's findings, so this verification does not downgrade or resolve their threads.

Named follow-up (nonblocking): endpoint-specific providers.*.endpoints[].extraHeaders remains outside is_secret_path() and held_secrets(). A supported endpoint header such as APP-Code therefore remains visible when a tool prints Raven's config; the generic home-config redactor does not catch that arbitrary header name. This requires endpoint-specific custom headers plus a tool read of the config, so at this late review round I am carrying it as a narrow follow-up rather than a blocker.

Verification: the focused self-configuration, permission, scrubbing, channel, and provider suite passed (765 passed). The full suite completed with 27052 passed, 133 skipped, 1 failed; the sole failure is the reproducible tests/test_cli_theme.py::test_bold_accent_renders_styled_not_bare on an untouched file, while every GitHub check including all four unit shards is green. git diff --check passes for both the fix delta and the full PR.

Covered this round: AGENTS.md/CLAUDE.md, CONTEXT-MAP.md and the relevant runtime terms; the full github/main...HEAD inventory and the complete fix delta; affected gate, writer, schema, scrubber, provider and channel callers; commit history and compatibility; test changes for weakening; and the self-configuration, Config-with-cargo, Permission Gate, and credential-boundary architecture.

[gloryfromca]

No blockers; suggestions only, and they are marked inline.

The new commit is a conflict-free merge of current main; its doctor warning, identity guidance, and deliverable-cache changes do not alter the self-configuration fixes. All previously blocking review threads are now resolved. The already named endpoint-header follow-up is unchanged and remains nonblocking, so I have not repeated it.

Verification: the focused self-configuration, permission, secret-scrubbing, doctor, deliverables, and identity-rendering tests pass (629 passed); git diff --check passes for both the merge delta and the full PR, and GitHub reports the PR checks green.

Covered this round: the repository rules and relevant runtime context, github/main...HEAD, the complete merge delta, affected callers and merge history, backward compatibility, test changes for weakening, and the self-configuration, Permission Gate, Config-with-cargo, identity, and RPC transport boundaries.

[gloryfromca]

Blocking: reject nonexistent channel and sub-agent configuration targets before smart review.

I reviewed the 40161c3..7982d68 delta and the full main diff, including the repository rules, the gate/registry/tool call order, affected writers and persistence callers, commit history, backward-compatibility implications, and whether the tests were weakened. The focused runs passed: 246 config/security tests and 705 gate, registry, journal, and sub-agent tests; both full-PR and revision git diff --check passed. One concrete pre-review validation gap remains, marked inline.

[gloryfromca]

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

Reviewed the complete 7982d68..83ad36a delta and the supporting gate, writer, channel-declaration, and catalog paths. The fix validates scalar, object, and batch channel targets with the writer's own declarations and preserves valid aliases and sub-agent settings; the added tests strengthen rather than weaken coverage. uv run pytest -q tests/test_raven_config_tool.py tests/test_config_self_surface.py passed (231 tests), and both revision and full-PR git diff --check passed.

[0xKT]

Not blockers -- four items from a full-diff pass at 83ad36a. The blocking findings from this pass are the three review threads (rules.py, held_secrets.py, redact.py).

N1 permissions.mode writes the default, not the conversation's mode (self_surface.py:699, raven_config.py _value_view)
The tool reads and writes the file default only. A web conversation that set its own mode in the picker keeps it: the user sets this chat to full, then asks Raven to go back to ask; the tool replies Set permissions.mode: ... -> "ask". It takes effect from the next turn, and the gate (gate.py:114, session_mode(...) or cfg.mode) still reads the session's full next turn. The reply is wrong in the unsafe direction. The other way round, "make this chat full" widens the default for every conversation without its own mode, channels included. Fix: give it a session scope like session.model (config.set with scope: "session"), or at least say in the reply that this conversation has its own mode X and only the default changed. Fine as a follow-up if you prefer.

N2 a batch set can leave a partial write and report only the error (raven_config.py:855-901)
The docstring says every value is checked before anything is written, but subagents.* entries are appended unchecked (873-875) and channel / sub-agent entries are not checked for a missing RPC caller. Example: {"agents.defaults.temperature": 0.5, "subagents.codex.enabled": "yes"} writes the temperature, then returns only Error: subagents.codex.enabled takes true or false. Fix: pre-check sub-agent fields and the caller in the first pass, or refuse subagents.* / channels.* in a batch to match SKILL.md ("Channels and sub-agents are changed one call each"); include the lines already applied when a later write fails.

N3 Risk section: memory now follows the main model (plugins-dist/everos-memory/raven_everos/config.py)
Summary mentions it, Risk does not. A user who never pinned the memory LLM gets long-term memory working after the upgrade, extracting on the main model and billed to the main provider's key, and EverOS restarts when the main model changes. Worth one line in Risk and the release notes (and how to keep it off).

N4 comment in gate.py:152-153 says a channel message is unattended
raven/gateway/spine.py:120 binds a responder for channel user turns on purpose ("A channel user can answer a question, so they can answer an approval"), so channel turns are attended and the code behaves as designed. Only the comment is wrong: drop "or a channel message".

Smaller items seen, no action needed in this PR: the deferred reload / restart gives up silently after 600s busy, lent_key_env reads only apiKey (not apiKeyList), opening an approval card sweeps away a docked credential card in the same conversation, the catalog's tools.exec.timeout has no upper bound (writer allows 5..3600).

[arelchan]

On the non-blocking items in the review summary: N1 fixed in 342735e (the reply now says when this conversation keeps its own approval mode; a session scope for permissions.mode is left as a follow-up); N2 fixed in 342735e (a batch checks sub-agent values and the services it needs before writing anything, and a write refused partway names what already took); N3 added to the Risk section of the description; N4 comment corrected in 342735e. The smaller items you listed are left as you suggested.

🤖 Addressed by Claude Code

[gloryfromca]

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

Reviewed the full 83ad36a..1ac64e2 delta: all five changed production files, relevant callers and history, backward compatibility, test changes, the permission/config architecture, and repository rules. I independently verified that valued global options can no longer disguise mutating package-manager commands as reads, ordinary header values are preserved while credential headers are scrubbed, and reads under Raven home no longer corrupt source while other home-dotfile configuration remains redacted. I found no new issue.

Verification: uv run pytest tests/test_permissions_gate.py tests/test_raven_config_tool.py tests/test_security_untrusted_context.py -q passed (463 tests), and both diff checks passed. The combined run with tests/test_cli_theme.py was 516 passed / 1 failed; the same theme test fails in isolation, but GitHub reports the current base as cad436c, which is the commit that introduced that identical test-only change, so it is not caused by this PR delta.

[0xKT]

Not a blocker -- R1-R3 re-checked against 1ac64e2: the package-manager bypass shapes (plus npm -g install x, npm --global --prefix ls install x) now ask, ordinary header values survive while Authorization / X-Api-Key are replaced, and ~/.raven/workspace / ~/.raven/tmp reads are left alone while ~/.qwen/settings.json is still redacted.

One gap from the R3 fix, tracked as a follow-up in #842 rather than held against this PR: skipping all of Raven's home also skips ~/.raven/oauth/<provider>/..., and those sign-in tokens are not in config.json, so neither scrub pass covers them. Repro and suggested fix are in the issue. Merging this as is.