[HALDRO]

Warning: Experimental Fix — Please Review Carefully

This PR addresses a real bug observed in production sessions but the fix is relatively new and has not been extensively tested. Please do not merge if anything looks wrong — feedback and corrections are very welcome.

Problem

RTK compression was applying keepPatterns/stripPatterns to all tool-role messages by matching on text content alone (via contentPatterns in detectCommandType).

This caused false positives: a TypeScript source file read via the built-in Read tool — containing a string like error TS2322 in an example, comment, or JSDoc — would match the build-typescript detector and get filtered down to error-only lines. The model would then see a heavily truncated file and assume the Read tool was broken, falling back to bash cat/head workarounds.

Confirmed via session log analysis: model reasoning explicitly stated 'read tool seems to be returning only partial content' and switched to bash fallbacks.

This aligns with how the official rtk-ai/rtk CLI works: 'hook only runs on Bash tool calls. Claude Code built-in tools like Read, Grep, and Glob do not pass through the Bash hook.'

Fix

In applyRtkCompression(), build a tool_call_id to toolName/command lookup from preceding assistant tool_calls entries. For each tool-role message:

• Shell tools (bash, shell, terminal, run_command, execute_command, exec, command) — pass the command string to processRtkText, filters apply as before
• Non-shell tools (read, grep, glob, edit, write, etc.) — skipFilters=true, keepPatterns/stripPatterns are skipped
• tool_call_id not found in lookup — existing text-based detection, fully backward compatible

smartTruncate and deduplication still apply to all tool results regardless of skipFilters.

Shell tool regex pattern taken from existing isTerminalTool() in open-sse/executors/grok-web.ts to stay consistent with project conventions.

What Was Not Changed

• smartTruncate behavior (still applies to all tool results)
• Deduplication behavior
• Any filter catalog entries
• Behavior when tool_call_id is absent (backward compatible)

Testing

• npx tsc --noEmit --skipLibCheck — clean, no errors in changed file
• rtk-engine.test.ts — 6/9 pass, 3 pre-existing failures confirmed on unmodified code

Uncertainty

Not 100% certain tool_call_id lookup will always be present in all provider formats (Anthropic, Gemini, etc.). If absent, code falls back to existing content-based detection — worst case is old behavior, not a regression.

Alternative Approach Worth Considering

This fix works at the message routing level — deciding per tool_call_id whether to apply filters. But there may be a cleaner fix on the detection side: tighten contentPatterns in the filter catalog so they require higher confidence before matching (e.g. require commandMatched in addition to contentMatches, or raise the confidence threshold). That would prevent false positives at the source rather than routing around them. The current approach is safer and more explicit, but the detection-side fix might be more correct long-term.

[kilo-code-bot]

Kilo Code Review could not run — your account is out of credits.

Add credits or switch to a free model to enable reviews on this change.

[gemini-code-assist]

Code Review

This pull request introduces selective RTK filtering by distinguishing between shell and non-shell tool results. It implements a lookup mechanism to associate tool outputs with their originating tool metadata, ensuring filters are only applied to relevant terminal-like commands. Feedback suggests enhancing the robustness of the tool argument parsing to handle non-string inputs and potential null values from JSON parsing, as well as optimizing performance by hoisting the shell tool detection regular expression out of the message processing loop.

[gemini-code-assist]

The current implementation for extracting the command argument has two potential issues:

1. It only handles fn.arguments when it is a string. Some providers or internal transformations may pass arguments as a pre-parsed object.
2. JSON.parse can return null (e.g., if the input is the string "null"), which would cause an error when accessing args.command or args.cmd. Although wrapped in a try-catch, it's better to explicitly check the type and value of args for robustness.

      const rawArgs = fn.arguments;
      let args: any = null;
      if (typeof rawArgs === "string") {
        try {
          args = JSON.parse(rawArgs);
        } catch {
          // non-JSON arguments
        }
      } else if (rawArgs && typeof rawArgs === "object") {
        args = rawArgs;
      }

      if (args && typeof args === "object") {
        command =
          typeof args.command === "string"
            ? args.command
            : typeof args.cmd === "string"
              ? args.cmd
              : null;
      }

[gemini-code-assist]

The regular expression for identifying shell tools is instantiated on every iteration of the messages.map loop. To improve performance and avoid redundant compilation, this regex should be defined as a constant outside the applyRtkCompression function.

[diegosouzapw]

Muito obrigado pela contribuição, @HALDRO! A integração foi concluída com sucesso.