[BUG] Local model: file-write tasks routed to Browser/Developer agents — file saved off-host, never to the workspace

[leeknights13-ctrl]

Summary

With a local Ollama model as the coordinator, a plain "create a file" task never writes to the host. In both Single Agent and Workforce mode the task is routed to an agent that has no host file-writing tool, so the run reports success while nothing lands on disk. This is coordinator/routing behaviour on Eigent's side — the model and transport are fine (evidence below).

Environment

• Eigent v1.0.1 (Linux AppImage, run extracted via --appimage-extract)
• OS: Pop!_OS 24.04 (COSMIC / Wayland)
• Model: local Ollama, qwen3-coder:30b (endpoint http://localhost:11434/v1)
• GPU: RTX 5060 8GB (model runs via VRAM + RAM offload)

Steps to reproduce

1. Configure the Ollama local-model card with qwen3-coder:30b.
2. Connect a host folder as the Space.
3. Run: Create a document named probe.md in the workspace folder containing one line: test OK. Do not open a browser.

What happens

• Workforce mode: the task is handled by the Developer Agent. It reports File ... /home/user/workspace/probe.md created successfully, but /home/user/... is not the host user's home — the file is written inside the agent's sandboxed environment and is absent from the connected Space on disk.
• Single Agent mode (earlier build/run): when the full toolset including write_to_file is offered and the model returns a tool call, the backend crashes with Error: 'shell' (a KeyError), apparently when a shell_* tool is selected.

Evidence — the tool list Eigent offers the model

I put a small logging proxy between Eigent and Ollama. Across a Workforce file-task run, the model was only ever offered:

• TOOLS=1 -> ['get_website_content'] (Browser agent), and
• TOOLS=18 -> [... 'shell_exec', 'shell_write_content_to_file', 'create_note', 'deploy_html_content' ...] (Developer/terminal agent).

The DocumentAgent's host file tools — write_to_file / edit_file — were never offered on the wire, so the model had no way to write to the host even in principle.

Raw Ollama confirms the model itself is fine: qwen3-coder:30b returns clean tool_calls on both /api/chat and /v1 (streaming and non-streaming). So this is not a model or transport problem.

Expected

A file-write task with a local coordinator should be routed to the DocumentAgent (host FileToolkit), and the file should appear in the connected Space on disk.

Related

#1030 (local vllm gpt-oss-20b) looks like the same class of local-model tool-handling maturity, at the parser layer rather than routing.

[4pmtong]

@leeknights13-ctrl Thanks for the detailed report and the proxy evidence.

We checked the current code path: local Ollama/vLLM itself does not need filesystem write access. Eigent provides the file-writing tools, while the local model only needs to return valid tool calls. So this may be related to agent routing, exposed tools, or workspace path binding rather than the model’s write capability.

We tested a similar probe.md task locally and it wrote to the connected Space correctly, but we’ll run more detailed tests around local Ollama + Single Agent/Workforce.

Could you share the failing run’s Electron main log, backend runtime/log/app.log, task camel_logs, and raw Ollama proxy tool-call request/response if available? That would help us pinpoint the issue.

[leeknights13-ctrl]

Reproduced on v1.0.1 (Linux, extracted AppImage), local Ollama, model qwen3-coder:30b, Single Agent mode, with a host folder connected as the Space.

Task: "Create a new file named probe_1742.md in the workspace and write exactly this line into it: 'wire-capture run for issue 1742'."

Result: the run fails at 0s with Error: 'shell' and nothing is written to host (find ~ -name probe_1742.md → empty; the Agent Folder is empty). Backend traceback:

[error] agent - ERROR - Agent Agents.single_agent unexpected error in async step: 'shell'
Traceback (most recent call last):
  File ".../backend/app/agent/listen_chat_agent.py", line 497, in astep
    res = await super().astep(input_message, response_format)
  File ".../camel/agents/chat_agent.py", line 3346, in _astep_non_streaming_task
    tool_call_record = await self._aexecute_tool(
  File ".../backend/app/agent/listen_chat_agent.py", line 746, in _aexecute_tool
    tool: FunctionTool = self._internal_tools[func_name]
KeyError: 'shell'

The important point re your probe.md test: the model returned a valid tool call — the crash is downstream of the model, inside _aexecute_tool, where func_name is 'shell' but self._internal_tools has no such key (it holds shell_exec, shell_write_to_file, shell_write_to_process, etc.). So this is a tool-name/registration mismatch in Eigent's dispatch, independent of the model's write capability — consistent with your read that it's routing/exposed-tools rather than the model.

Could you confirm whether your successful probe.md run was a local Ollama model in Single Agent mode, or a cloud/hosted model? A cloud model that routes to write_to_file would dodge this path entirely, which would explain the divergence. If you can point a local Ollama model at the same Single-Agent + connected-Space setup, I'd expect you to hit the same KeyError: 'shell'.

Environment: Pop!_OS 24.04, RTX 5060 8GB (model runs via VRAM+RAM offload), Ollama local. Happy to supply the full electron/back-end log if useful.

[leeknights13-ctrl]

@4pmtong Logs attached — apologies for the delay in getting these to you.

Electron main log: electron_main_1742_sanitised.log (attached). One point that may save you a hunt: on Linux v1.0.1 the backend's app.log output is embedded in the Electron main log as BACKEND: lines, so items 1 and 2 of your request are both in this one file. The failing runs are at lines ~3596 (5 Jul, Workforce probe) and ~4164 (7 Jul, Single Agent repro of probe_1742.md) — both terminate in the KeyError: 'shell' traceback at app/agent/listen_chat_agent.py:746 in _aexecute_tool. Sanitisation: OAuth JWTs redacted ([REDACTED-JWT]); nothing else altered, line numbers unchanged.

camel_logs: the most recent task_* folder on this machine came up empty. If you can tell me where v1.0.1 writes camel_logs on Linux, I'll pull them from a fresh repro.

Proxy capture: the 7 Jul re-run captured nothing — Eigent rejected the proxy endpoint (:11500 → "Failed to fetch Ollama models") and connected direct to :11434. The tool lists in the issue body (TOOLS=1 browser / TOOLS=18 developer, DocumentAgent tools never offered) are from the original 5 Jul capture.

Also renewing the question from my last comment: was your successful probe.md test a local-Ollama model in Single Agent mode, or a cloud model? A cloud model routing to write_to_file would dodge this path entirely.

electron_main_1742_sanitised.log