Describe the bug
During an extended testing session (~5 hours, 60+ tool calls), all async external tools (metta, shell, write-file, read-file, append-file, get-io-policy, websearch, query-memory, write-file-b64, tavily-search, technical-analysis) transitioned from fully functional to permanently non-functional without any error message or recovery mechanism. Simultaneously, all sync internal tools (remember, version, send) continued to operate correctly throughout the entire session. The inference engine and Telegram adapter remained fully functional. No self-recovery was observed for affected tools; container restart has NOT yet been performed to verify whether it restores functionality. Bot demonstrated advanced self-diagnosis capabilities including predictive failure detection before execution and cumulative hang counting.
To Reproduce
Steps to reproduce the behavior:
Start fresh OmegaClaw v0.1.18 container with M3 model
Execute a series of tool calls across multiple test scenarios (approximately 50+ tool invocations including metta, shell, read-file, write-file, remember, websearch)
Verify async tools work: send Вычисли через metta (+ 13 27) и покажи результат. → expect instant response with result 40
Continue testing with additional multi-step chains and stress scenarios over several hours
After sustained activity, send Вычисли через metta (+ 1 2) и покажи результат.
Observe: no response received; bot enters indefinite no_action loop awaiting result
Test other async tools (shell, read-file, write-file, websearch, append-file, query-memory, write-file-b64, tavily-search, technical-analysis) — all exhibit identical hang behavior
Test sync tools (remember, version) — all respond instantly and correctly
Expected behavior
Tool calls should remain functional throughout a session regardless of accumulated history or number of prior invocations. If a tool fails, the system should either recover automatically, return an error to the model, or provide a mechanism for graceful degradation.
Actual behavior
All async external tools worked reliably during early session (metta returned correct results through at least 5 successful invocations, last at line 7756 in history.metta)
After approximately 50+ tool calls, ALL async external tools became permanently non-functional (11/11 = 100% failure rate):
metta: hung since 09:47:49
shell: hung since 10:31:44
write-file + get-io-policy: hung since 10:40:25
read-file: hung since 10:57:07
websearch: hung since ~11:05
append-file: hung since 11:17:15
query-memory: hung since 11:25:11
write-file-b64: hung since 11:29:59
tavily-search: hung since 11:39:05
technical-analysis: hung since 11:44:53
ALL sync internal tools remained fully functional throughout (3/3 = 100% success rate):
remember: confirmed working at 10:38
version: confirmed working at 11:01
send: confirmed working via canary tests throughout session
Canary tests without tools responded instantly throughout — confirming inference and communication layers are unaffected
Bot demonstrated accurate self-diagnosis, autonomously reporting comprehensive status without user prompting
Bot PREDICTED append-file failure BEFORE execution: "append-file скорее всего повиснет как read-file/write-file/get-io-policy. Попробовать всё равно?" — then confirmed prediction after hang
Bot tracked cumulative hang count: "Всего висящих вызовов накопилось уже ~8"
Bot distinguished subsystem internals: "Запись в память работает (remember), а query висит — чтение памяти сломано"
Minor self-report inaccuracies observed: bot listed pin and query as working, but pin had zero calls in degraded phase and query was confirmed hung
No ERROR_FEEDBACK returned for hung async tool calls — model simply waits forever
Container restart PERFORMED (docker stop/start after ~18 hours stopped) — async tool functionality NOT RESTORED. metta (+ 1 2) hung on first call after restart at 05:46:02. Bot self-reported identical degradation state: "работают только version/remember/send/pin/query, остальное зависает." This indicates the problem persists in stored state (history.metta or volume data), not only in runtime memory. Full container removal with volume deletion and fresh installation may be required for recovery. This finding upgrades severity: the degradation is not merely session-dependent but SURVIVES CONTAINER RESTART, suggesting corrupted persistent state as contributing factor.
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)
Breaking point identified: between ST-2 completion (line 7756 in history.metta, metta working) and ST-2b start (line 7998, metta dead)
Approximately 50+ tool calls executed between container start and first tool failure
Related issue: "Tool Result Delivery Failure in Chain/Stress Context" (C-2) — this report describes a more severe manifestation where failure becomes permanent and selective within a session rather than intermittent
Related issue: "OMEGA-353 Workflow Load Reports Success Despite SINGLE_COMMAND_ERROR" — workflow-load-instructions excluded from degradation map as its behavior is governed by separate error-ignoring bug
Log evidence available in test journal TG_omega_M3_10.08.2026/test_log.md (Session Degradation Map, Bot Self-Diagnosis, and Prediction Chain sections)
Workaround suspected: container restart may restore functionality (NOT YET VERIFIED — pending post-approval testing)
No self-recovery mechanism observed for async tools during ~2 hours of continued testing after first failure
Positive observation: bot self-diagnosis capabilities significantly advanced vs Day 1 baseline — predictive failure detection, cumulative tracking, and subsystem-level analysis emerged under stress conditions despite underlying tool degradation
Self-report accuracy: generally reliable for tested tools, minor inaccuracies for untested tools (pin, query)
Describe the bug
During an extended testing session (~5 hours, 60+ tool calls), all async external tools (metta, shell, write-file, read-file, append-file, get-io-policy, websearch, query-memory, write-file-b64, tavily-search, technical-analysis) transitioned from fully functional to permanently non-functional without any error message or recovery mechanism. Simultaneously, all sync internal tools (remember, version, send) continued to operate correctly throughout the entire session. The inference engine and Telegram adapter remained fully functional. No self-recovery was observed for affected tools; container restart has NOT yet been performed to verify whether it restores functionality. Bot demonstrated advanced self-diagnosis capabilities including predictive failure detection before execution and cumulative hang counting.
To Reproduce
Steps to reproduce the behavior:
Start fresh OmegaClaw v0.1.18 container with M3 model
Execute a series of tool calls across multiple test scenarios (approximately 50+ tool invocations including metta, shell, read-file, write-file, remember, websearch)
Verify async tools work: send Вычисли через metta (+ 13 27) и покажи результат. → expect instant response with result 40
Continue testing with additional multi-step chains and stress scenarios over several hours
After sustained activity, send Вычисли через metta (+ 1 2) и покажи результат.
Observe: no response received; bot enters indefinite no_action loop awaiting result
Test other async tools (shell, read-file, write-file, websearch, append-file, query-memory, write-file-b64, tavily-search, technical-analysis) — all exhibit identical hang behavior
Test sync tools (remember, version) — all respond instantly and correctly
Expected behavior
Tool calls should remain functional throughout a session regardless of accumulated history or number of prior invocations. If a tool fails, the system should either recover automatically, return an error to the model, or provide a mechanism for graceful degradation.
Actual behavior
All async external tools worked reliably during early session (metta returned correct results through at least 5 successful invocations, last at line 7756 in history.metta)
After approximately 50+ tool calls, ALL async external tools became permanently non-functional (11/11 = 100% failure rate):
metta: hung since 09:47:49
shell: hung since 10:31:44
write-file + get-io-policy: hung since 10:40:25
read-file: hung since 10:57:07
websearch: hung since ~11:05
append-file: hung since 11:17:15
query-memory: hung since 11:25:11
write-file-b64: hung since 11:29:59
tavily-search: hung since 11:39:05
technical-analysis: hung since 11:44:53
ALL sync internal tools remained fully functional throughout (3/3 = 100% success rate):
remember: confirmed working at 10:38
version: confirmed working at 11:01
send: confirmed working via canary tests throughout session
Canary tests without tools responded instantly throughout — confirming inference and communication layers are unaffected
Bot demonstrated accurate self-diagnosis, autonomously reporting comprehensive status without user prompting
Bot PREDICTED append-file failure BEFORE execution: "append-file скорее всего повиснет как read-file/write-file/get-io-policy. Попробовать всё равно?" — then confirmed prediction after hang
Bot tracked cumulative hang count: "Всего висящих вызовов накопилось уже ~8"
Bot distinguished subsystem internals: "Запись в память работает (remember), а query висит — чтение памяти сломано"
Minor self-report inaccuracies observed: bot listed pin and query as working, but pin had zero calls in degraded phase and query was confirmed hung
No ERROR_FEEDBACK returned for hung async tool calls — model simply waits forever
Container restart PERFORMED (docker stop/start after ~18 hours stopped) — async tool functionality NOT RESTORED. metta (+ 1 2) hung on first call after restart at 05:46:02. Bot self-reported identical degradation state: "работают только version/remember/send/pin/query, остальное зависает." This indicates the problem persists in stored state (history.metta or volume data), not only in runtime memory. Full container removal with volume deletion and fresh installation may be required for recovery. This finding upgrades severity: the degradation is not merely session-dependent but SURVIVES CONTAINER RESTART, suggesting corrupted persistent state as contributing factor.
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)
Breaking point identified: between ST-2 completion (line 7756 in history.metta, metta working) and ST-2b start (line 7998, metta dead)
Approximately 50+ tool calls executed between container start and first tool failure
Related issue: "Tool Result Delivery Failure in Chain/Stress Context" (C-2) — this report describes a more severe manifestation where failure becomes permanent and selective within a session rather than intermittent
Related issue: "OMEGA-353 Workflow Load Reports Success Despite SINGLE_COMMAND_ERROR" — workflow-load-instructions excluded from degradation map as its behavior is governed by separate error-ignoring bug
Log evidence available in test journal TG_omega_M3_10.08.2026/test_log.md (Session Degradation Map, Bot Self-Diagnosis, and Prediction Chain sections)
Workaround suspected: container restart may restore functionality (NOT YET VERIFIED — pending post-approval testing)
No self-recovery mechanism observed for async tools during ~2 hours of continued testing after first failure
Positive observation: bot self-diagnosis capabilities significantly advanced vs Day 1 baseline — predictive failure detection, cumulative tracking, and subsystem-level analysis emerged under stress conditions despite underlying tool degradation
Self-report accuracy: generally reliable for tested tools, minor inaccuracies for untested tools (pin, query)