Both "Critical" items in this review reference files that aren't in this PR's diff.

Verified against GET /repos/QwenLM/qwen-code/pulls/3236/files — head 5b1ffd9, 6 files changed, +577/−16:

• .gitignore
• packages/core/src/core/coreToolScheduler.ts (+ test)
• packages/core/src/services/loopDetectionService.ts (+ test)
• packages/core/src/telemetry/types.ts

1. packages/sdk-java/.../AssistantContent.java:49 — the entire packages/sdk-java/ tree is untouched by this PR. No rename of ThingkingAssistantContent → ThinkingAssistantContent happens here.
2. packages/core/src/index.ts:77-116 — packages/core/src/index.ts is not in the changed-files list. No exports for EditTool, ShellTool, ExitPlanModeTool, or TodoWriteTool are altered by this PR.

For context, the three inline comments from the earlier 02:50 UTC review pass (repetitive-thoughts window, isReadLikeTool substring match, per-tool validationRetryCounts pruning) were all addressed in commit 5b1ffd9 before this second review ran.

— Claude Opus 4.7 (xhigh) via Claude Code

Thanks for the iterations — the per-tool validationRetryCounts pruning and the READ_LIKE_TOOL_NAMES exact-set + read_/list_ prefix fallback are clearly better than the earlier pass. A few concerns remain after a close re-read at head 5b1ffd9:

1. thoughtHistory is never cleared between tool calls within a single prompt

In addAndCheck, ToolCallRequest calls resetContentTracking() which wipes streamContentHistory / contentStats, but thoughtHistory is only cleared in reset(promptId). And reset(promptId) only runs on UserQuery / Cron / Notification (see packages/core/src/core/client.ts around loopDetector.reset(prompt_id)). One user prompt can drive many tool roundtrips in a single turn, so thoughtHistory accumulates across the whole chain. Sequence like:

• Content "I should check..." (push)
• ToolCallRequest (real progress)
• Content "I should check..." (push)
• ToolCallRequest
• Content "I should check..." (push) → third identical entry → REPETITIVE_THOUGHTS fires

even though the intervening tool calls represent real progress. Either clear thoughtHistory inside resetContentTracking(), or scope repetition to a single content stream.

2. trackThoughtPatterns hooks Content, not Thought

In this codebase, model thinking is yielded as a distinct GeminiEventType.Thought event (see packages/core/src/core/turn.ts, getThoughtText(resp) → yield { type: Thought, ... }), separate from GeminiEventType.Content. The new detector only runs on Content events, so it never actually sees thought text — only hedged phrasing (should, might, could, etc.) in regular output. If the intent is "detect repetitive reasoning", Thought events need to be handled too. If the intent is "detect repeated hedge prefixes in prose output", the name and the inline comment referring to "internal reasoning" are misleading.

3. READ_FILE_LOOP fires on legitimate initial exploration

With FILE_READ_THRESHOLD = 5 and FILE_READ_WINDOW = 10, a very common opening pattern — list_directory followed by four read_file calls — hits the threshold on the 5th tool call (all 5 are read-like). "Explain the architecture of X" or "summarize this directory" tasks routinely start with exactly this shape and will trip the detector on their first productive moves. Options: raise the threshold (e.g. 8 / 15), or exempt early windows that contain only read-like tools (fresh exploration vs. post-action re-reading).

4. PR description mentions changes not present in the diff

The TLDR lists "Fix EAGAIN pty errors and schema generation build", but the 6 changed files at head 5b1ffd9 (.gitignore, coreToolScheduler.ts + test, loopDetectionService.ts + test, telemetry/types.ts) don't touch pty handling or schema generation. Either the description is stale or those commits are missing.

Minor: .gitignore gains benchmark_test_dir/, which doesn't seem related to loop detection — worth a separate PR or dropping.

E2E-verified that the READ_FILE_LOOP false-positive is real, not hypothetical. On the PR head with model.skipLoopDetection: false:

• Prompt: Summarize what this project is and briefly describe what each source file does. Be concise.
• Target: a 4-file toy project (README.md, package.json, src/{config,index,utils}.ts)
• Model: gpt-5.4 via DashScope OpenAI-compatible

The model issued 5 parallel read_file calls in one assistant turn. Instrumenting LoopDetectionService.addAndCheck shows the 5th call trips it:

[LOOPDET] name=read_file recent=5 readLikes=5 sameNameStreak=5
          toolCallLoop=false readFileLoop=true actionStagnation=false

The non-interactive run then exits with empty stdout — no visible reason surfaced to the user.

Two small asks before merge:

1. Raise FILE_READ_THRESHOLD / FILE_READ_WINDOW to something like 8 / 15, or add a cold-start exemption so the first window of read-likes (which is almost always legitimate opening exploration on a new project) doesn't count as loop evidence. Update the corresponding test to match.
2. Non-interactive mode currently fails silently when a loop is detected. At minimum, print a one-liner to stderr so users know what happened and which detector fired.

Separately: one behavioral note worth surfacing — packages/cli/src/config/config.ts:1148 defaults skipLoopDetection to true, so none of the new detectors run for default users. Not asking to flip that here, but it means this PR's detector logic is only exercised by users who opt in, and the unit tests enshrine thresholds that break on the first real-world opt-in workload.

Everything else — per-tool validationRetryCounts pruning, Thought-based repetition detection, exact-name + read_/list_ prefix matching for read-like tools, the cross-turn history clearing on ToolCallRequest — looks good.