Do not expose tools for standalone text-only LLMRunner tasks

[sirenexcelsior]

Summary

This PR removes tool exposure from the standalone LLMRunner when enableTools=false.

Why

Some standalone text-only tasks, such as L1 extraction, expect plain text output and do not need tool access. Passing even a read-only tool subset can still encourage tool-calling behavior on OpenAI-compatible backends, which makes this path less stable than necessary.

With this change:

• enableTools=true keeps the existing sandboxed tool behavior
• enableTools=false sends no tools at all

Scope

• src/adapters/standalone/llm-runner.ts

Notes

This is intentionally narrow and only affects the standalone runner's text-only path.

[Maxwell-Code07]

Thanks for this fix! We've noticed this issue as well. On certain reasoning models, the L1 extraction path can run into problems like what's described in #58. We'll review this and follow up with you soon.

[withRiver]

@sirenexcelsior

After reviewing the relevant code, I can explain why a read_file tool was being passed in.

This project originally reused OpenClaw's runEmbeddedPiAgent to send requests to and receive responses from the LLM. If you pass disableTools: true to runEmbeddedPiAgent, it ends up sending "tools": [] in the HTTP payload to the LLM API. However, some LLM providers (e.g. qwencode) reject requests where the tools field is an empty array. To work around this, the developer had no choice but to include a minimal, low-impact tool — read_file — so the array would never be empty.

StandaloneLLMRunner does not use OpenClaw's runEmbeddedPiAgent, yet it mistakenly carried over the read_file tool inclusion. For StandaloneLLMRunner, there is absolutely no need to pass read_file — doing so only degrades the LLM's output quality.

After I removed read_file based on your PR, the model was able to correctly extract L1 memories. So I believe removing read_file in the PR is the right fix. However, I don't think it's necessary to add the disableThinking configuration — that part of the PR feels a bit heavy-handed. For issue #58, simply removing read_file is sufficient.

[sirenexcelsior]

Thanks a lot for the thorough investigation and explanation. This was very helpful, and I learned a lot from the background on why read_file was originally included in the first place.

Your clarification makes perfect sense: the workaround was necessary in the runEmbeddedPiAgent path to avoid sending "tools": [], but it should not have been carried over to StandaloneLLMRunner. I agree that, for the standalone path, removing read_file is the right and sufficient fix.

Based on your feedback, I have updated this PR to remove the disableThinking part and keep the change focused on the read_file removal only.

Thanks again for taking the time to trace this through so carefully.

[withRiver]

@sirenexcelsior
Could you please modify the title and content of this PR? Focus on removing the tools for the standalone LLMRunner. After completing the above modifications, this PR can be merged.

Thanks for your contribution!

[sirenexcelsior]

Updated the PR title and description to focus only on removing tools from the standalone LLMRunner text-only path. Thanks for the guidance.