Sub-agent tool calls requiring confirmation are never approved

[nitbx]

I had an issue with sub-agents (e.g. executor) not executing their tasks, returning only a stub response like "I'll search systematically..." and forcing the main agent to redo the work inline.

The root cause I found is that when a sub-agent (researcher, executor, introspector) makes tool calls that require confirmation (=:confirm t=), the confirmation overlay is rendered in the parent chat buffer at the parent agent's position markers. This overlay is hidden behind the parent's own task overlay ("Waiting..."), so the user never sees or interacts with it. The sub-agent's initial text response is returned as the final result before any tools actually run.

If I didn't understand correctly, feel free to realign me. I'm a neophyte in Lisp.

Love your toolset. <3

[nitbx]

Tentative fix and/or improvement.

#67

[karthink]

That's odd, I see and act on sub-agent tool call confirmations all the time. They show up exactly like the parent agent's tool call confirmation prompts, at the (current) end of the response. Do you have a screenshot showcasing the problem?

[phrb]

I'm having a similar problem, but I can't confirm if it has the same mechanism.
Sub agents often return empty or simply stop early.
I'll attempt to reproduce and debug, then reach out when I have more information.

[phrb]

I'm having a similar problem, but I can't confirm if it has the same mechanism. Sub agents often return empty or simply stop early. I'll attempt to reproduce and debug, then reach out when I have more information.

I don't know why this is happening, but I have two examples where agents stop early and return "sparse results", as Claude puts it. I'm using the GitHub backend, and Claude Opus 4.6.

It does not seem related to tool use though, here are the examples:

#+begin_tool (Agent :subagent_type "introspector" :description "Explore gptel debugging fa ...)
(:name "Agent" :args (:subagent_type "introspector" :description "Explore gptel debugging facilities" :prompt "I need to understand what debugging facilities exist in gptel and gptel-agent. Please investigate:

1. Any variables related to debugging/logging (grep for \"debug\", \"log\", \"trace\", \"verbose\" in gptel customization variables)
2. The *gptel-log* buffer - how it works, what gets logged there
3. Any FSM debugging or state inspection tools
4. How to inspect tool call/response payloads
5. How gptel-agent--task works for sub-agent debugging
6. Any relevant hooks that could be used for debugging (gptel-pre-response-hook, gptel-post-response-hook, etc.)
7. Check if there's a gptel-log-level or similar variable

Return a concise summary of all debugging-relevant variables, functions, buffers, and hooks you find."))

Introspector result for task: Explore gptel debugging facilities

I'll systematically investigate all debugging facilities in gptel and gptel-agent. Let me start with broad discovery.
#+end_tool
#+begin_tool (Agent :subagent_type "researcher" :description "Find gptel debugging pattern ...)
(:name "Agent" :args (:subagent_type "researcher" :description "Find gptel debugging patterns" :prompt "Search the gptel and gptel-agent source code for debugging-related patterns. Look in:
- /home/phrb/.emacs.d/elpa/gptel-20260218.1003/
- /home/phrb/.emacs.d/elpa/gptel-agent/

Specifically find:
1. Any references to \"*gptel-log*\" buffer or gptel-log function
2. Uses of `message` for debugging output
3. Any `edebug` or `debug-on-entry` friendly functions (interactive ones, key entry points)
4. How errors are handled and surfaced (search for \"error\", \"signal\", \"condition-case\")
5. The FSM transition debugging - how to watch state changes
6. Any HTTP request/response logging
7. Tool execution error handling in gptel-agent-tools.el

Return a concise, organized summary of what you find - focusing on practical debugging techniques a user could employ."))

Researcher result for task: Find gptel debugging patterns

I'll search systematically across both codebases for debugging-related patterns.
#+end_tool
The agents returned sparse results. Let me dig in directly.

[bschwand]

UPDATE: I do not think my issue is related, it also happens when I disable tool confirmation. I'll file a separate issue.

I might be having the same issue, the agent works for a while then eventually gets stuck waiting on the researcher but in fact nothing is happening.

meanwhile last lines of gptel.log shows

{"gptel": "request Curl command", "timestamp": "2026-03-01 21:07:15"}
curl
--disable
--location
--silent
--compressed
-XPOST
-y7200
-Y1
-D-
-w(cc32a7252e9dd26b597ec6c69553156b\ .\ %{size_header})
--data-binary
@/var/folders/bk/fy5hm18s4tz129zk94k9ht740000gn/T/gptel-curl-dataYLZwoZ.json
-HContent-Type:\ application/json
http://files:8080/v1/chat/completions

and that file has been downloaded sucessfully. the local llm shows the last request completed and llama-server is idle. So it looks like gptel is stuck on something.

[karthink]

@nitbx I've been trying to reproduce the problem of tool call confirmation prompts from sub-agents not appearing in the buffer, but I haven't been able to. This is what I see:

A tool call confirmation from Executor subagent.

Moreover, the code that is run to display this tool call confirmation is the same as the one that the main agent runs. So I think the root cause may not be this.

---

@phrb Your issue looks different. It will be useful to look at the log. Can you turn on logging (setq gptel-log-level 'info) and produce the full JSON log of the interaction? I can examine what the sub-agent is doing there.

[phrb]

@karthink I've attached a log where I launched 3 agents.
One of them finished and two got stuck on the tool confirmation problem.

Here's where it got stuck. You can't see the third agent because it finished:

I also saw some of these:

error in process sentinel: let: Wrong type argument: stringp, nil
error in process sentinel: Wrong type argument: stringp, nil
error in process sentinel: let: Wrong type argument: stringp, nil
error in process sentinel: Wrong type argument: stringp, nil

gptel_log.json

[phrb]

@karthink, I was now able to reproduce the agents not returning data.

Here goes the log and a screenshot:

gptel_log.json

[karthink]

One of them finished and two got stuck on the tool confirmation problem.

@phrb I've pushed a possible fix for this problem to gptel (not gptel-agent). Could you update gptel and check if failures because of tool call confirmations from multiple simultaneous Agents is still an issue?

I'm not yet sure what's happening in the other case, still looking into it.

[phrb]

Update: I encountered the problem where a sub-agent does not return anything again, so that one was not solved by the gtpel fix. I'll try to reproduce it in an isolated chat and upload the .json file.

@karthink your fix to gptel seems to have fixed my other problem as well.
I can now see all agents' tool requests and approve them directly in the buffer, and agents seem to go all the way with their work. Was that an issue with concurrent requests?

I'll be sure to report back if I hit any other corner cases.
Here's the screenshot and log file.

gptel_log.json

[karthink]

@phrb That's good to hear. Waiting to hear if @nitbx's issue is fixed as well.

[phrb]

@karthink I've been able to reproduce the bug with sub-agents returning empty or incomplete responses.

Attached are a screenshot, the gptel logs, and my conversation in .org (sent in .txt because github doesn't like uploading .org files).

gptel_log.json

gptel_conversation.txt

[karthink]

@phrb Thanks for the report. As it turns out, figuring out what is happening from the log with five interweaving sub-agents making tool calls is nearly impossible. I'll need to add more structured introspection to the sub-agent interface to be able to diagnose this.

If you can reproduce the error with just one sub-agent call, that would be very helpful. If you try, please also turn off streaming with (setq gptel-stream nil) as it makes the log much easier to read.