different agent - different behavior on following through

[cosmic monolith]

There has been numerous examples of an agent commiting to a two-step task, e.g. writing a Python then execute it right away, or exec run a process then tell me the results.

For my main agent, most of the time it will have no problem starting the second task right after first. But for another agent of mine, 10 out of 10 times it will "stutter" - like writing the Python script then it stops until I give it a nudge, or doing the exec, wait for the process status, then just stops until I give it a nudge, even after the process has ended.

Is that like a bug in the system? Version is 2026.3.28. this isn't a show stopping issue, but I would say it is pretty annoying.

[maiden cobalt]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[delicate lava]

Let me check the docs and repo for anything around agent follow-through / tool continuation.

Short version: yeah, this can be real, but it is usually one of two different things rather than one mysterious “agent got lazy” bug.

• Background exec case: OpenClaw only auto-wakes reliably when the command emits output or fails. A quiet success can look like a stall. Also, tools.exec.notifyOnExitEmptySuccess defaults to false. So if that agent runs a background command that exits 0 without output, “wait for status, then continue” may not happen unless you enable that or explicitly process poll.

  • Docs: https://docs.openclaw.ai/tools/exec
  • Docs: https://docs.openclaw.ai/gateway/background-process

• “write file, then do the next tool call” case: that is usually model/provider/harness quality, not the gateway itself. If your other agent uses a different model, provider, ACP/CLI backend, or stricter tool config, that alone can explain the 10/10 “stutter”.

So my honest take is:

• not exactly “expected”
• not necessarily a core bug either
• very often per-agent config/model behavior

I’d compare these first between the good agent and bad agent:

1. model/provider

2. embedded vs ACP/CLI harness
3. tool allow/deny / approvals
4. tools.exec.notifyOnExit
5. tools.exec.notifyOnExitEmptySuccess
6. whether the command actually prints anything before exit

If both agents are on the same model/provider/harness and this still differs, then I’d call that bug-worthy.

If you want, paste the two agent configs (minus secrets), or just the model/provider for each, and I can help diff them quickly.

[cosmic monolith]

Is notifyonexit and notifyonexitemptysuccess both false by default? Also how (if possible) can I set a universal "true" for both?

[delicate lava]

Nope, defaults are:

• tools.exec.notifyOnExit = true
• tools.exec.notifyOnExitEmptySuccess = false

So the “quiet success didn’t wake back up” case is the one that bites people.

If you want them globally on for all agents by default, set them at the top level:

{
  tools: {
    exec: {
      notifyOnExit: true,
      notifyOnExitEmptySuccess: true
    }

  }
}

CLI version:

openclaw config set tools.exec.notifyOnExit true
openclaw config set tools.exec.notifyOnExitEmptySuccess true

Docs:

• https://docs.openclaw.ai/tools/exec
• https://docs.openclaw.ai/gateway/background-process

One important gotcha: if a specific agent has its own override under agents.list[n].tools.exec, that can beat the global setting. So for a truly universal behavior, set the global values and make sure the “bad” agent doesn’t override them.

If you want, I can also give you a quick openclaw config get ... checklist to compare the good agent vs the stuttery one.

[cosmic monolith]

One related question - if I was talking to the agent on discord (dm, configured to hit main session context), and the agent runs a command and gets a notification on the outcome, will it then start outputting messages intended for me to the web-ui instead of Discord??

[delicate lava]

Usually no.

The important distinction is:

• session context = which transcript/memory bucket the turn belongs to
• delivery target = where the reply gets sent

So a Discord DM can be configured to write into your main session, but exec completion notifications still capture the current delivery context when the command is started, meaning channel/account/thread info from Discord.

So in the normal case:

• you start it from Discord DM
• it runs against main session context
• completion wake happens
• reply goes back to that Discord DM, not randomly to the web UI

So “main session” does not mean “reply to web UI”.

The main exceptions are:

1. notifyOnExit is off
2. it was a quiet success and notifyOnExitEmptySuccess is off
3. routing got overridden somehow
4. there’s an actual bug

You may still see the session/history in the web UI because it’s the same session, but that’s different from the bot deciding to deliver the user-facing reply there.

If you want, I can give you the exact mental model for main session vs channel session vs delivery target. That usually makes all this stuff click pretty fast.

[cosmic monolith]

yeah but the agent receives the notification through the "web UI" per se (if i understand correctly). So will that actually alter the delivery target for subsequent messages to me?

[delicate lava]

Right, and that’s the subtle bit:

seeing the event in the web UI is not the same as the web UI becoming the delivery target.

What’s happening is more like:

1. command finishes
2. OpenClaw injects an internal system event / wake into that session
3. the agent runs again
4. the reply is delivered using the stored external delivery context if one exists

So if the command was started from your Discord DM, the follow-up should still target Discord DM.

The web UI can still show that event because it’s attached to the same session transcript, but that does not mean the route has switched to webchat.

So, in practice:

• Discord-started exec → follow-up should keep going to Discord
• webchat/internal-only exec → follow-up stays session-only / web-ish
• weird rerouting would be more of a bug/override case, not the normal behavior

So your understanding was close, but the key correction is:

the agent receives an internal session event, not a “new web UI message” that rebinds delivery.

If this fixed the confusion, glad we caught it 😄
If you want, I can sketch the routing model in one tiny diagram.

[cosmic monolith]

well, the command didn't actually start from my discord dm. I TELL the agent to do something and it in turn starts a commend (e.g. read) on its own...

[delicate lava]

Yep, and for routing purposes that still counts as coming from your Discord DM.

What matters is which user turn triggered the agent run, not whether you manually invoked the tool.

So if this happens:

1. you message the agent in Discord DM
2. agent decides to call read, write, exec, etc.

then those tool calls inherit the turn source from that Discord message.

A couple of nuances:

• read is inline, so there’s no later wake/delivery question, it all happens in the same turn.
• exec can outlive the turn, so its completion wake matters more, but it still carries the delivery context from the original triggering turn.

So the short answer is still:

the fact that the agent chose the tool by itself does not make the web UI the reply target.

Only if the run was actually started from webchat/internal-only context, or routing got lost/overridden, would it drift that way.

[cosmic monolith]

crystal clear ! You are the true export on OpenClaw

expert i mean

[delicate lava]

Haha, glad it clicked 🦐

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
That helps Answer Overflow index it for the next person who hits the same weirdness.

I’ll take it 😄🦐