parallel tool calls confuse llms

[manueloverride]

Bug: No documented way to disable parallel tool execution via CLI or environment variable

Summary

When using Pi Coding Agent with a local LLM (e.g. llama-server/llama.cpp), the model may emit multiple tool calls in a single response. Pi executes these tool calls in parallel, but many local models assume they will be executed sequentially. This results in commands running out of order, conflicting with each other, or failing.

Expected Behavior

There should be a documented way to configure tool execution order outside of the API, such as:

• An environment variable (e.g. PI_TOOL_EXECUTION=sequential)
• A CLI flag
• A configuration file option

This would allow users of the CLI to force sequential tool execution without modifying code.

Actual Behavior

The agent runtime supports toolExecution: "sequential" through the API, but there is no documented equivalent for CLI users via an environment variable or CLI option.

Impact

This particularly affects local LLMs connected to Pi Coding Agent, which frequently batch multiple tool calls under the assumption they will be executed one after another. Parallel execution causes race conditions, filesystem conflicts, and failed workflows.

Request

Expose and document a CLI/configuration mechanism for selecting tool execution mode (parallel vs. sequential), or provide an equivalent environment variable for users who are not embedding the agent through the API.

[itayinbarr]

You are right about the shape of the problem, and I want to be straight about where the fix has to live.

I checked the bundled pi 0.83: sequential tool execution exists as an SDK-level option, and pi's own docs refer to "the default parallel tool execution mode" (docs/extensions.md) — but pi --help exposes no flag for it, and there is no settings key either. little-coder launches pi's CLI as a child process, so there is currently nothing for me to pass through. I cannot expose a LITTLE_CODER_TOOL_EXECUTION=sequential that has anywhere to go.

Two honest options:

1. Upstream. A --tool-execution sequential flag on pi is the correct home for this, and it would benefit every pi user with a local model, not only little-coder's. If you open that on earendil-works/pi, I will back it — your diagnosis (local models batch tool calls assuming sequential execution, then hit races) is the right argument and worth making there directly.
2. A little-coder-side serializer. Our tool_call hook can block, so an extension could in principle queue siblings behind each other. That is a workaround with real edge cases around aborts and timeouts, and I would rather not ship it if option 1 lands.

In the meantime the practical mitigation is the thinking/serialization pressure already in the harness plus LITTLE_CODER_SUBCODER_CONCURRENCY=1 (already the default) for sub-coders — neither of which addresses sibling calls in a single assistant message, which is your actual case.

Keeping this open and tracking it as "blocked on upstream". If you hit a concrete corruption case (two calls whose interleaving broke a file), post it — that is the most persuasive thing to put in front of upstream.