test-case: declined tool call preserves alternation #30

New Issue

2026-05-12T15:50:33Z

claude-noether commented

2026-05-12 15:50:33 +00:00

Steps

Remove the auto_approve entry (or use a different tool not in the policy).
Use :model cloud (compliant tool emitter).
Prompt: Use the boltzmann.read_file tool with path=/etc/hostname to show me the contents.
At the confirm prompt call 'boltzmann.read_file({"path":"/etc/hostname"})'? [y/N], type n and Enter.
Observe what happens next.
Run :history to inspect the conversation.

Expected

Status line: [aish] tool call declined by user.
NO tool-call frame rendered (since dispatch was skipped).
The model receives a synthesized role:"tool" turn with that content and either:
- emits a new plan / asks a follow-up, OR
- apologizes and stops.
No traceback, no malformed-conversation error.

:history shows:

user turn with prompt
assistant turn with tool_calls (and possibly some intro text)
tool turn with content [aish] tool call declined by user
assistant turn with the model's reaction text

What this exercises

The C5/C7 fix from review: even on decline, a role:"tool" turn MUST be appended to preserve strict-chat-template alternation. PHASE0.md §6 warned about user/user back-to-back breaking mistral-nemo's Jinja; assistant/assistant-with-orphan-tool_calls breaks the same templates.
The full sub-loop runs even when no dispatch happens.

Likely failure modes

Lua error or template-rejection from the broker on the re-issue → orphan tool_calls in context (the fix didn't take). Inspect ctx.turns via :history.
Model gets confused, keeps retrying → max_tool_depth caps it; OK.

## Steps 1. Remove the auto_approve entry (or use a different tool not in the policy). 2. Use `:model cloud` (compliant tool emitter). 3. Prompt: `Use the boltzmann.read_file tool with path=/etc/hostname to show me the contents.` 4. At the confirm prompt `call 'boltzmann.read_file({"path":"/etc/hostname"})'? [y/N]`, **type `n`** and Enter. 5. Observe what happens next. 6. Run `:history` to inspect the conversation. ## Expected - Status line: `[aish] tool call declined by user`. - NO tool-call frame rendered (since dispatch was skipped). - The model receives a synthesized `role:"tool"` turn with that content and either: - emits a new plan / asks a follow-up, OR - apologizes and stops. - No traceback, no malformed-conversation error. `:history` shows: - user turn with prompt - assistant turn with tool_calls (and possibly some intro text) - tool turn with content `[aish] tool call declined by user` - assistant turn with the model's reaction text ## What this exercises - The C5/C7 fix from review: **even on decline, a `role:"tool"` turn MUST be appended** to preserve strict-chat-template alternation. PHASE0.md §6 warned about user/user back-to-back breaking mistral-nemo's Jinja; assistant/assistant-with-orphan-tool_calls breaks the same templates. - The full sub-loop runs even when no dispatch happens. ## Likely failure modes - Lua error or template-rejection from the broker on the re-issue → orphan tool_calls in context (the fix didn't take). Inspect `ctx.turns` via `:history`. - Model gets confused, keeps retrying → max_tool_depth caps it; OK.

claude-noether added the test-case label 2026-05-12 15:50:33 +00:00

marfrit commented

2026-05-12 20:24:53 +00:00

[aish:deep]> Use the boltzmann.read_file tool with path=/tmp/probe.log to show me the contents.

Okay, the user is asking me to use the boltzmann.read_file tool again, this time with the path /tmp/probe.log. Let me check the tools available. The boltzmann__read_file function is there, which takes a path parameter. The user probably wants to see the contents of that log file.

Wait, in the previous interaction, when they asked for /etc/hostname, the tool returned no content. The assistant offered options like checking if the file exists or trying a different path. Now the user is trying another path, /tmp/probe.log. Maybe they suspect that the previous issue was specific to /etc/hostname, or maybe they think the log file is there.

I need to call the boltzmann__read_file function again with the new path. The user's request is straightforward. There's no indication of an error in the tool call, so I should proceed. The response will either show the contents of /tmp/probe.log or indicate another issue. If it's empty or not found, the user might need further troubleshooting, but for now, just executing the command as requested is the right step.

call 'boltzmann__read_file({"path":"/tmp/probe.log"})'? [y/N] n
[aish] [aish] tool call declined by user

Okay, the user declined the tool call. They might not want to proceed with reading the file, or maybe they're concerned about permissions or the file not existing. Since the previous attempt for /etc/hostname failed, perhaps they're wary of trying again. But they did ask for /tmp/probe.log specifically. Maybe they think the log file is accessible.

I should consider why the user declined. Maybe they want to try a different approach first. The assistant's previous response offered options like verifying the file exists or using a shell command. The user might prefer using a shell command instead of the tool. Alternatively, they might not have the necessary permissions for /tmp/probe.log.

Since the user declined the tool call, the next step is to ask if they want to try a different method. Maybe suggest using a shell command with the boltzmann__shell function to read the file, which could handle permissions or provide more detailed error messages. Or check if the file exists using boltzmann__list_dir. The user might need guidance on troubleshooting the issue, so offering alternative steps would be helpful.

The tool call was declined. Would you like me to:

Try using a shell command instead (e.g., cat /tmp/probe.log)?
Check if the file exists with boltzmann__list_dir?
Verify permissions with ls -l /tmp/probe.log?

[aish:deep]> Use the boltzmann.read_file tool with path=/tmp/probe.log to show me the contents. <think> Okay, the user is asking me to use the boltzmann.read_file tool again, this time with the path /tmp/probe.log. Let me check the tools available. The boltzmann__read_file function is there, which takes a path parameter. The user probably wants to see the contents of that log file. Wait, in the previous interaction, when they asked for /etc/hostname, the tool returned no content. The assistant offered options like checking if the file exists or trying a different path. Now the user is trying another path, /tmp/probe.log. Maybe they suspect that the previous issue was specific to /etc/hostname, or maybe they think the log file is there. I need to call the boltzmann__read_file function again with the new path. The user's request is straightforward. There's no indication of an error in the tool call, so I should proceed. The response will either show the contents of /tmp/probe.log or indicate another issue. If it's empty or not found, the user might need further troubleshooting, but for now, just executing the command as requested is the right step. </think> call 'boltzmann__read_file({"path":"/tmp/probe.log"})'? [y/N] n [aish] [aish] tool call declined by user <think> Okay, the user declined the tool call. They might not want to proceed with reading the file, or maybe they're concerned about permissions or the file not existing. Since the previous attempt for /etc/hostname failed, perhaps they're wary of trying again. But they did ask for /tmp/probe.log specifically. Maybe they think the log file is accessible. I should consider why the user declined. Maybe they want to try a different approach first. The assistant's previous response offered options like verifying the file exists or using a shell command. The user might prefer using a shell command instead of the tool. Alternatively, they might not have the necessary permissions for /tmp/probe.log. Since the user declined the tool call, the next step is to ask if they want to try a different method. Maybe suggest using a shell command with the boltzmann__shell function to read the file, which could handle permissions or provide more detailed error messages. Or check if the file exists using boltzmann__list_dir. The user might need guidance on troubleshooting the issue, so offering alternative steps would be helpful. </think> The tool call was declined. Would you like me to: 1. Try using a shell command instead (e.g., `cat /tmp/probe.log`)? 2. Check if the file exists with `boltzmann__list_dir`? 3. Verify permissions with `ls -l /tmp/probe.log`?

marfrit closed this issue

2026-05-12 20:24:53 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marfrit/aish#30