[kylehgc]

Conflicted Sync of upstream/develop (head fc19d7a, tag dev-0.50.0-rc.427, 95 commits since the 2026-09-07 sync) into fork develop, per the CONTEXT.md Conflicted Sync policy: topic branch, upstream wins, only proven-additive fork code survives.

Full writeup: claudedocs/sync-conflict-2026-09-11.md.

Conflict and how it was resolved

File	Colliding upstream work	Resolution
src/hooks/hook_cmd.rs	Hook decision consolidation (rtk-ai#3955, KuSh: d6ce8f7, 6eb915b): decide/decide_for_agent/suppress_identity and HookDecision move to a new src/hooks/decision.rs; decide_from_verdict becomes a shim	Both hunks upstream's verbatim. The fork's local get_rewritten and enum HookDecision go (upstream owns them now). The fork's three already-rtk assert arms go: AllowRewrite(cmd) when every segment is already rtk and the verdict is Allow (30557a6, 371e058), AskRewrite(cmd) for an already-rtk Ask or an unattestable already-rtk shape (505e355, 31fceff). Upstream's suppress_identity is an explicit policy for the identity-rewrite case — Defer, with the Gemini trade-off documented and the contract pinned in tests/hook_decision_protocol_test.rs — so the fork's arms are a competing opinion, not an addition.

Consequential removals outside the hunks, all dead or unreachable once the arms are gone: all_segments_already_rtk and permissions::is_wrapped_invocation (only callers were the Allow arm; -D dead-code flagged both), and the rewritten == cmd early-returns in the Copilot IDE, Vibe and Droid renderers (31fceff) that suppress_identity now makes unreachable for every hook.

Additive fork code kept, proved absent upstream (git show upstream/develop:src/hooks/permissions.rs | grep -c 'normalize_for_matching\|is_rtk_prefixed\|COMMAND_WRAPPERS' → 0): the rtk-aware permission matcher from the still-open upstream rtk-ai#3195 adoption (30557a6, albatrossflyon-coder; 8adbeba, 505e355 amendments) and the already-rtk Deny assertion in the Claude hook. Deny is checked before suppress_identity can run, so rtk rm -rf / and rtk proxy rm -rf / still come back denied against a Bash(rm:*) rule.

Cargo.toml in the range: version 0.42.4 → 0.48.0 and a direct toml_edit = "0.22" (already in the lock via toml; lock diff is the version line only). No build.rs change.

Fork tests removed

Eighteen hook_cmd.rs tests that pinned the removed arms or renderer guards, or could no longer fail without them — full list in the writeup. test_probe_shapes_fail_safe's two contains_already_rtk_segment asserts moved into test_contains_already_rtk_segment_ignores_original_form. permissions.rs: test_is_wrapped_invocation_contract dropped with its subject. Kept and still green under upstream's decide: the deny-through-prefix and wrapper see-through tests, the already-rtk deny payload test, and every matcher test.

Fork delta

371e058 and 31fceff added to HEALED_SHAS: their headline behavior is superseded by upstream d6ce8f7. 30557a6, 8adbeba, 505e355, d9e7458 stay — the deny path, wrapper see-through and rtk run wrapper entry are live, even though two of those commit subjects still name the removed assert behavior.

User-visible change

With an allow rule for the underlying tool and nothing to rewrite, an already-rtk command (rtk grep foo under Bash(grep:*)) used to get an explicit permissionDecision: "allow" from the Claude hook; it now gets no hook output, and Claude Code's own matcher decides. Same for an already-rtk ask rule or redirect. Deny through the rtk prefix is unchanged.

Repro, real binaries (before = installed develop build of 2026-09-08, after = this branch)

Sandboxed CLAUDE_CONFIG_DIR with {"permissions":{"deny":["Bash(rm:*)"],"allow":["Bash(grep:*)"],"ask":["Bash(git push:*)"]}}, scratch RTK_DB_PATH.

$ printf '{"tool_name":"Bash","tool_input":{"command":"<cmd>"}}' | rtk hook claude

rtk grep foo
before: {..,"updatedInput":{"command":"rtk grep foo"},"permissionDecision":"allow"}
after:  <silent>

rtk git push origin main
before: {..,"updatedInput":{"command":"rtk git push origin main"},"permissionDecision":"ask"}
after:  <silent>

rtk git log > /tmp/out.txt
before: {..,"updatedInput":{"command":"rtk git log > /tmp/out.txt"},"permissionDecision":"ask"}
after:  <silent>

rtk rm -rf /tmp/x
before/after: {..,"permissionDecision":"deny","permissionDecisionReason":"RTK: matches a configured deny rule"}

rtk proxy rm -rf /tmp/x
before/after: {..,"permissionDecision":"deny","permissionDecisionReason":"RTK: matches a configured deny rule"}

git status
before/after: {..,"updatedInput":{"command":"rtk git status"},"permissionDecision":"ask"}

Review round

Independent read-only reviewer pass over the resolution against the writeup's claims: verbatim-vs-upstream on the conflict region, additive proofs by grep on upstream's copy, guard reachability under suppress_identity, dropped/kept test lists, stale references, HEALED_SHAS notes. All nine checks passed (conflict span byte-identical to upstream by cmp; decision.rs byte-identical; every non-test hunk vs upstream accounted for). Four findings, all taken: the unattestable-ask arm and is_wrapped_invocation were introduced by fork d9e7458, not 505e355/31fceff — attributions corrected, and d9e7458 stays in the delta because its rtk run wrapper entry is live; test_decide_defer_for_already_rtk_command_with_no_matching_rule could no longer fail under suppress_identity — dropped; the 371e058 healed note pointed at the wrong commit for the surviving strip_token rule — fixed; a caveat on the generated README rows for 505e355/d9e7458 added to the writeup. Gate re-run after the changes.

Quality gate

x64 host toolchain (scripts/win-dev-env.ps1): cargo fmt --all clean · cargo clippy --all-targets 0 warnings · cargo test --all 3540 unit tests passed, 0 failed, 8 ignored; all integration suites green, including upstream's new hook_decision_protocol_test, git_show_blob_differential_test and signal_flush_test. git diff --check clean.

Deliberately not done

• Upstream fix(hooks): honor permission rules for already-rtk-prefixed commands rtk-ai/rtk#3195 is still open. The fork keeps its matcher and deny assertion; whether the identity-rewrite Allow/Ask assertions should come back is a question for that PR's review upstream, not for a sync. If they should, that is a fresh Original fix against upstream's decision.rs, with its own ticket.

🤖 Generated with Claude Code