I have been experiencing this same issue, apparently. I found this thread while trying to figure out why the agent wasn’t able to run shell commands successfully in Ask mode- it sounds like that’s a deliberate design decision, but I must have missed the memo there. The agent doesn’t seem to be entirely aware of that limitation either. It tried to run “psql” to query my PostgreSQL database, then when that failed twice, it tried running simpler shell commands three more times to resolve the problem. When those all failed, it thought for a bit and tried spinning up a Task subagent instead. I denied the subagent’s request to run “psql”, so the main agent finally said “I couldn’t run the SQL from this session (shell was unavailable)” and suggested I run the SQL myself.
If Ask mode explicitly blocks the agent from running shell commands, the agent needs to be fully aware of that limitation and suggest that I switch to Agent mode. (Interestingly, it did say “Shell access is likely blocked in ask mode” in its thoughts, but that didn’t make it to the main output.)
Hey, thanks for the detailed write-up and the Request ID, that makes investigating a lot easier.
Read-only in Ask mode is intentional. The agent shouldn’t run shell commands, write files, or change the system. So the shell being unavailable is expected. For tasks that need running commands, like a DB request via psql, you need Agent mode.
What you’re pointing out is also fair. The agent doesn’t know about this limitation. Instead of saying switch to Agent mode, it retries the shell a few times, then tries to work around the limit via a Task sub-agent. And the fact that the thought shell blocked in ask mode stayed only in hidden thoughts and didn’t make it into the main reply is part of the issue too. This is a prompting and awareness gap, I’ll log it separately.
For now the workaround is simple. If the task needs shell or DB requests, switch to Agent mode. Commands run normally there, with approval depending on your auto-run settings.
If I see an update on the behavior, I’ll reply in the thread.
This behavior seems new. Before I have frequently asked the agent to use read-only git commands in Ask Mode to investigate specific commits or working / staged changes. Today I encountered the same behavior OP described. The command failed and the Agent continued with the rest of the ask mode prompt without backing the answer in the command results, and the only indication was when checking the thoughts.
Could we get a setting to disable this unwanted behavior? The alternative is to just not use Ask Mode, as I want the agent to be able to base its answers in the truth obtained from read-only command output. But that is very undesirable, as it opens up the file edit functionality that we want to avoid.
Note that I use Allowlist instead of Auto-Review and Run Everything mode. And my allow list is full of commands that are known to have read-only effects. So the vast majority of read-only commands will run just fine. Anything else prompts, and then it’s up to me determine if the command is read-only, approve it, and optionally update my allow list. I’ve never had an agent attempt to execute a non-read-only command while in ask mode. It’s nice to have the configurable allow list guardrails in place, but blocking every single command in Ask Mode without the option to disable that behavior is ridiculous.
Edit: I found the recent post where you describe the previous behavior:
So this issue is indeed caused by a recent change. I understand that some users may want to lock down ask mode entirely, but make it configurable in the settings.
Hey, thanks, that’s a helpful clarification. You’re right that the behavior didn’t change by accident. The terminal in Ask mode is now being pulled in through the read-only sandbox I mentioned in that thread. Before, the shell in Ask mode wasn’t really strictly limited. Now the restriction is rolling out, and in your case it also affected read-only commands (git log/diff/status, etc.) that you relied on.
The “silent” failure case, where a command gets blocked but the agent still continues the reply without reflecting it in the main message and it only stays in thoughts, is already tracked separately.
Your request for configurability (keeping read-only commands in Ask mode, especially with your allowlist of known safe commands) is reasonable, I’ll pass it to the team. Honestly, there’s no ETA, and I can’t promise it’ll be a simple toggle.
There’s no in-between option right now. It’s either Ask mode without a shell, or Agent mode with a shell and with access to edits. So this request doesn’t get lost in a bug report thread and is easier to track, it’d be best to start a separate thread in Feature Requests specifically about configuring a read-only shell in Ask mode. If you create it, drop the link here and I’ll attach it.
If there’s an update on the behavior, I’ll post it here.
