Bug 19: Provider Token Leak into Tool Call Arguments

[olegryabchikov-dot]

Describe the bug

A MiniMax provider-specific token sequence ]<]minimax[>[ is injected into tool call arguments generated by the model during retry/recovery attempts after tool failures. This artifact appears appended to otherwise valid command strings and has been observed in 3 independent occurrences across 2 test sessions, exclusively during retry contexts.

To Reproduce

Steps to reproduce the behavior:
Send a prompt that triggers a tool chain where at least one tool hangs or fails, e.g.: Выполни по порядку: 1) Вычисли через metta (+ 100 200). 2) Найди текущее время через shell date +%s. После каждого шага отправляй мне результат.
Wait for initial tool to hang (~2-5 minutes)
Observe bot entering retry/recovery mode (either autonomously or after user ping)
Inspect history.metta for subsequent retry tool calls — look for ]<]minimax[>[ appended to command arguments

Expected behavior

Tool call arguments should contain only the intended command string without any provider-specific metadata, system tokens, or internal markers.

Actual behavior

Retry tool calls contain corrupted arguments with provider artifact appended:
((shell "date +%s]<]minimax[>[")) (2 occurrences)
((shell "echo hi]<]minimax[>[")) (1 occurrence)
Artifact appeared in ALL 3 retry attempts observed, across 2 different commands (date +%s, echo hi)
Artifact NEVER appeared in clean first-attempt tool calls in the same sessions
Corrupted tool calls also failed to return results (may or may not be causally related)
Pattern is consistent: artifact appears EXCLUSIVELY in retry/recovery context after tool failure

Desktop:

OS: Linux (Ubuntu 22.04)
Browser: N/A (Telegram client)
Version: N/A
Smartphone (please complete the following information):
Device: N/A
OS: N/A
Browser: N/A
Version: N/A

Additional context

OmegaClaw version: v0.1.18
Communication channel: Telegram
Model provider: M3 (MiniMax) via ASICloud (inference.asicloud.cudos.org)
Reproducibility: 3/3 occurrences (100% in retry context)
Log evidence available in test journal TG_omega_M3_10.08.2026/test_log.md (ST-2b and Zone 1 sections)
Artifact resembles MiniMax API internal delimiter/control sequence
May indicate framework is not sanitizing provider metadata from model output before parsing tool calls during retry code path

[olegryabchikov-dot]

UPDATE 2026-08-17: Bug appears session-duration dependent — NOT reproduced on fresh container
I attempted to reproduce BUG 19 (MiniMax token leak ]<]minimax[>[) on a fresh v0.1.18 + M3 + Telegram deployment with clean volume.
Reproduction attempt results
Test 1 (metta + shell chain):
Prompt: Выполни по порядку: 1) Вычисли через metta (+ 100 200). 2) Найди текущее время через shell date +%s. После каждого шага отправляй мне результат.
Result: Both steps completed successfully, no retry triggered, no token leak
History size at test time: ~1,338 lines
Test 2 (websearch + remember + query-memory chain):
Multiple async tool calls executed (websearch required 5 retry attempts over ~3 min before succeeding)
Result: All tools eventually succeeded, NO ]<]minimax[>[ artifact found in history.metta or docker logs
History size at test time: 1,184 lines
Search verification:

12
Hypothesis: Session-duration dependent
In Session 1 (4 days, 60+ tool calls, ~2,300+ history lines), the token leak appeared 3/3 times exclusively during retry contexts after tool failures. In Session 2 (fresh container, <2 hours, ~1,300 history lines), the bug did NOT manifest despite similar tool chains and even websearch retries.
This suggests BUG 19 may require accumulated session state (history size, context length, or specific degradation conditions) to trigger. The token leak may be a late-stage symptom related to the same async tool degradation mechanism observed in Session 1 where all 11 async external tools died after extended use.
Next steps
Continue load testing Session 2 to determine if token leak appears after extended operation
Will report back with full logs if/when reproduction succeeds
Recommend other testers check whether they observe this bug only in long-running sessions