Agent gets stuck in sudo loop - becomes unusuable

I haven't reproduced this in my current test. A screenshot of the test shows the agent executing:

sudo -n /usr/bin/id

with output:

uid=0(root) gid=0(root) groups=0(root)

This confirms that this command succeeded without an interactive password prompt in that environment. It does not distinguish a NOPASSWD rule from valid cached sudo credentials, and it does not reproduce the reported authorization/retry sequence or the behavior after reaching the iteration limit.

My tentative interpretation is that there may be two separate problems: the privileged command fails to execute, and the agent keeps retrying the unfinished task even after the user changes the subject. I don't yet have evidence that sudo authorization actually expires after one conversation turn; authentication may never have succeeded, or a later execution may not share the same authentication context.

Could you share:

• The exact command and its raw tool output/error, with secrets removed.
• What "authorization" involved: entering a sudo password, authenticating in a separate terminal, approving an execution prompt, or replying to the agent in chat.
• The model ID and a short conversation/tool trace covering the initial failure, authorization attempt, iteration-limit response, and subsequent change of subject.

That should help distinguish a sudo/execution-session issue from the agent's handling of repeated tool failures and new user instructions.

My problem is not about sudo (my agent runned as root user)

It just that sometimes it enter loops until i stop it.

Thanks for clarifying and sharing the screenshot. I can see the repeated messages and commands, and I understand that your case is unrelated to sudo.

I'd like to try reproducing this with the DeepSeek model you mentioned. Could you share the exact model ID for "deepseek v4 flash 0731", the provider you're using (for example, OpenRouter), and the prompt or task that triggered the loop? Your nanobot version and any relevant agent settings would also help me match your setup.

If available, could you also share a short, redacted log covering the step before the loop and two or three repetitions, including the tool calls and their results? Model request/response traces would be especially useful to check whether previous tool results reached the model, but whatever logs you already have would be a helpful starting point. Please remove API keys, credentials, and any private content before sharing.

This would help me distinguish repeated behavior from the model from a possible issue with how tool results or conversation history are passed back to it. Once I have the model ID and triggering task, I'll try the same setup and, if I can reproduce it, compare it with another model.

It never happenned with other harnesses (omp, opencode, qwenpaw etc.) using the same provider.

My current provider is infron.ai Deepseek v4 0731:free model

But same problem on paid model : mimo 2.6 flash

Latest current nanobot version (installed 2 days ago)

I can't share my AGENTS.md, it's a big 2000 lines instructions related to debugging of a big perl script (about 4000 lines) for low-level system tasks (like partitionning etc.)

Building on #3700, which handles loops inside a turn: the part of this report that worries me is what happens after the turn ends.

Problem. When a turn stops at max iterations, the unfinished command stays in the history as the latest thing the agent was doing. So on the next message it picks the old task back up, even when the user has moved on. From the user's side, the agent is "obsessed".

Simpler fix. When a turn ends because of max iterations or a loop guard:

1. Add one short note to the history: "Stopped: tried X N times, it kept failing because Y. Not retrying unless asked."
2. Tell the user the same thing, in one line.
3. On the next turn, treat the new message as the task. Only go back to X if the user says so.

What to cut. Replaying the full failed tool loop into the next turn's context. The one-line summary is enough, and it saves tokens too.

How we'd know. A test where turn 1 hits max iterations on a failing command, and turn 2 asks something unrelated. Turn 2 should never call the failing command.

Thanks for the reports and discussion. #6346 is now merged into main. When a user turn reaches max_iterations, the next user turn receives guidance not to resume the unfinished task unless the user asks. Existing conversation history is retained.

This addresses the next-turn part of the report. It does not fix sudo authentication or all repeated tool calls within a turn, and the guidance is not a guarantee of model behavior. We will keep this issue open for those remaining cases. A short redacted reproduction on a build containing #6346, with the model ID and tool results, would help us verify what remains. This update refers to main, not a confirmed stable release.

I can confirm that i was using "deepseek v4 flash 0731" when the loop happend, and sudo worked normally in other scenarios. The model seems to be the problem

For the two remaining cases (sudo auth expiring mid-turn and repeated identical tool calls within a turn), two patterns that might help:

Sudo auth: Instead of a single-turn authorization, use a per-task grant keyed on the task ID. When the agent requests sudo for the first time in a task, mint a short-lived credential (e.g. 5-minute TTL) that covers all sudo calls within that task. The harness injects it as SUDO_ASKPASS_PATH rather than a one-shot password. This way the auth outlives the tool-call boundary but not the task, so it doesn't accumulate across unrelated requests.

Tool-call dedup: Before dispatching a tool call, hash the (tool_name, serialized_args) pair against a set of already-executed calls in the current turn. If the hash matches, inject a short system note ("you already ran this exact command; it returned X") and force the agent to choose a different action or produce a final answer. This is cheaper than a full loop-detection model call and catches the "obsessed with one command" pattern before it burns max iterations.