feat(openclaw): add broadcast groups with multi-model agents - #817
Conversation
Add sonnet and glm agents alongside main, and configure a parallel broadcast strategy so all three models respond to every WhatsApp message.
The wildcard "*" is not supported as a broadcast peer key. Use the actual WhatsApp group JID 120363425572081403@g.us so OpenClaw dispatches messages to all three agents (main, sonnet, glm).
|
You do not have enough credits to review this pull request. Please purchase more credits to continue. |
Summary of ChangesHello @shunkakinoki, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the 'openclaw' system by integrating multi-model agent capabilities and a new broadcast mechanism. It allows multiple language models to process and respond to messages concurrently within a designated chat group, significantly expanding the system's interactive potential and responsiveness. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds nine agents (code-reviewers, formatter, security scanner, test-coverage, docs-checker), introduces a top-level Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Mesa DescriptionTL;DREnable parallel multi-model replies in OpenClaw's Code Review WhatsApp group by adding broadcast groups and new agents. What changed?
Description generated by Mesa. Update settings |
There was a problem hiding this comment.
Code Review
This pull request introduces a broadcast feature to have multiple language models respond in parallel within a specific WhatsApp group. The implementation correctly adds new agents and the broadcast configuration. However, there is a significant issue with a hardcoded WhatsApp group ID in the configuration templates (openclaw.tpl.json and openclaw.template.json). This ID should be parameterized using a placeholder and substituted at runtime to improve the configuration's reusability and security. My review includes a specific suggestion to address this.
| }, | ||
| "broadcast": { | ||
| "strategy": "parallel", | ||
| "120363425572081403@g.us": [ |
There was a problem hiding this comment.
The WhatsApp group ID is hardcoded in this template. For better reusability and security, please replace it with a placeholder like __WHATSAPP_BROADCAST_GROUP__. You'll then need to update hydrate.sh to substitute this value at runtime, and regenerate openclaw.template.json.
| "120363425572081403@g.us": [ | |
| "__WHATSAPP_BROADCAST_GROUP__": [ |
There was a problem hiding this comment.
Pull request overview
This pull request adds a broadcast groups feature to OpenClaw that enables multi-model parallel responses. The PR configures three AI agents (Opus, Sonnet, and GLM) to respond simultaneously to messages in a specific WhatsApp group.
Changes:
- Added two new agents (
sonnetandglm) to the agents.list configuration alongside the existingmainagent - Introduced a
broadcastconfiguration section withparallelstrategy for a specific WhatsApp group - Both template (.tpl.json) and hydrated (.template.json) configuration files updated consistently
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| config/openclaw/openclaw.tpl.json | Template file with model placeholders for the new agents and broadcast configuration |
| config/openclaw/openclaw.template.json | Hydrated template with concrete model IDs matching models.json values |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@config/openclaw/openclaw.tpl.json`:
- Around line 199-211: The agent entries "sonnet" and "glm" set model.primary
but omit model.fallbacks, which can lead to either losing defaults or creating a
self-referential fallback for "glm"; update the "sonnet" and "glm" agent objects
to explicitly set model.fallbacks (e.g., for "sonnet" keep ["cliproxy/__GLM__"]
and for "glm" point to a different fallback such as Sonnet or Opus) instead of
relying on agents.defaults.model so that fallback resolution is explicit and
non-self-referential.
- Around line 214-221: The parallel broadcast entry for group
"120363425572081403@g.us" with agents ["main","sonnet","glm"] causes independent
per-agent session churn under interrupt queue mode; update the "broadcast"
configuration to avoid concurrent independent runs—either switch "strategy" from
"parallel" to "sequential" so agents run one after another, replace the three
agents with a single aggregator agent that fan-outs internally, or change the
queue mode to a global/centralized interrupt behavior if your runtime supports a
global interrupt flag; modify the entry containing the group id and the agents
list ("main", "sonnet", "glm") accordingly so interrupts are synchronized and
token/API duplication is avoided.
| }, | ||
| { | ||
| "id": "sonnet", | ||
| "model": { | ||
| "primary": "cliproxy/__CLAUDE_SONNET__" | ||
| } | ||
| }, | ||
| { | ||
| "id": "glm", | ||
| "model": { | ||
| "primary": "cliproxy/__GLM__" | ||
| } | ||
| } |
There was a problem hiding this comment.
New agents may lose default fallbacks; glm fallback is self-referential either way.
The sonnet and glm agents override model.primary without specifying fallbacks. Depending on how OpenClaw merges partial model overrides with agents.defaults.model:
- If it's a deep merge,
sonnetinheritsfallbacks: ["cliproxy/__GLM__"](fine), butglmends up with its own model as its fallback (useless). - If it's a shallow replace of the
modelkey, both agents lose fallbacks entirely.
Consider explicitly setting fallbacks for each agent — e.g., glm could fall back to Sonnet or Opus, and sonnet could keep the GLM fallback.
🤖 Prompt for AI Agents
In `@config/openclaw/openclaw.tpl.json` around lines 199 - 211, The agent entries
"sonnet" and "glm" set model.primary but omit model.fallbacks, which can lead to
either losing defaults or creating a self-referential fallback for "glm"; update
the "sonnet" and "glm" agent objects to explicitly set model.fallbacks (e.g.,
for "sonnet" keep ["cliproxy/__GLM__"] and for "glm" point to a different
fallback such as Sonnet or Opus) instead of relying on agents.defaults.model so
that fallback resolution is explicit and non-self-referential.
| "broadcast": { | ||
| "strategy": "parallel", | ||
| "120363425572081403@g.us": [ | ||
| "main", | ||
| "sonnet", | ||
| "glm" | ||
| ] | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
OpenClaw broadcast parallel strategy interrupt queue behavior
💡 Result:
In OpenClaw, these three pieces interact like this:
-
Broadcast +
strategy: "parallel": when a message is eligible for broadcast, OpenClaw fans it out to every listed agent, and those agents process simultaneously (unless you setstrategy: "sequential"). Each agent runs with an isolated session key and separate context, so they don’t share history or state. Responses can arrive in any order. [1] -
Queueing model (important for “parallel”): OpenClaw still serializes runs per session key (“only one active run per session”), while allowing parallelism across different session keys, subject to global concurrency limits. Because broadcast agents have different session keys, they can run concurrently. [2]
-
Queue mode
interruptbehavior:interruptis a legacy queue mode that aborts the active run for that session, then processes the newest inbound message for that same session. In a broadcast-parallel setup, this applies per agent session—interrupting one agent’s session won’t automatically stop the other broadcast agents’ runs, because they’re isolated sessions. [1][2]
Implication: with broadcast-parallel + interrupt, rapid-fire inbound messages can cause each broadcast agent to repeatedly abort and restart its own run, potentially producing fewer/shorter outputs and higher churn, while other agents may still complete depending on timing and per-session queue state. [1][2]
Sources: Broadcast Groups docs [1], Queue/Command Queue docs [2].
🏁 Script executed:
# Check if there's OpenClaw documentation or README in the repo
find . -type f -name "*.md" | head -20Repository: shunkakinoki/dotfiles
Length of output: 269
🏁 Script executed:
# Look for any OpenClaw-related code or documentation
git ls-files | grep -i openclaw | head -30Repository: shunkakinoki/dotfiles
Length of output: 264
🏁 Script executed:
# Check the actual configuration file for context around lines 214-221
head -250 config/openclaw/openclaw.tpl.json | tail -40Repository: shunkakinoki/dotfiles
Length of output: 816
🏁 Script executed:
# Search for documentation or code about broadcast strategy and queue modes
rg -i "broadcast|queue.*mode" --type json -A 2 -B 2 | head -100Repository: shunkakinoki/dotfiles
Length of output: 610
Parallel broadcast with interrupt queue mode creates independent session churn per agent.
Every message in group 120363425572081403@g.us will invoke all three models concurrently:
- 3× the token consumption and API costs per inbound message.
- Each agent runs in an isolated session with separate context—partial failure in one agent doesn't block others.
interruptqueue mode applies per-agent session, not globally. A new inbound message interrupts each agent's run independently. This means rapid messages can cause each broadcast agent to repeatedly abort and restart its own session, potentially producing incomplete outputs and independent timing mismatches across the three agents, not synchronized interrupts.
🤖 Prompt for AI Agents
In `@config/openclaw/openclaw.tpl.json` around lines 214 - 221, The parallel
broadcast entry for group "120363425572081403@g.us" with agents
["main","sonnet","glm"] causes independent per-agent session churn under
interrupt queue mode; update the "broadcast" configuration to avoid concurrent
independent runs—either switch "strategy" from "parallel" to "sequential" so
agents run one after another, replace the three agents with a single aggregator
agent that fan-outs internally, or change the queue mode to a global/centralized
interrupt behavior if your runtime supports a global interrupt flag; modify the
entry containing the group id and the agents list ("main", "sonnet", "glm")
accordingly so interrupts are synchronized and token/API duplication is avoided.
… group - Add gpt-codex and gemini-pro agents alongside main, sonnet, glm - Point broadcast to Code Review group (120363425148909388@g.us) instead of General group - All 5 models respond in parallel for code reviews
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@config/openclaw/openclaw.template.json`:
- Around line 226-235: Broadcast config targets the wrong group JID and includes
extra agents; verify and update the "broadcast" entry so the key JID matches the
intended target and the agent list matches the PR description. Specifically,
confirm whether the correct group JID is "120363425572081403@g.us" (General) or
"120363425148909388@g.us" (Code Review) and replace the current key under
"broadcast" accordingly, then remove or add agents in the array so it matches
the intended agent set (e.g., keep only "main", "sonnet", "glm" if the PR
intends three agents) by editing the JSON value for the "broadcast" object.
Code Review group (120363425148909388@g.us) broadcast config: 5 code reviewers (same workspace, different models): - code-reviewer-opus (Opus, fallback GLM) - code-reviewer-sonnet (Sonnet, fallback GLM) - code-reviewer-glm (GLM) - code-reviewer-gpt-codex (GPT Codex, fallback GLM) - code-reviewer-gemini (Gemini Pro, fallback GLM) 4 specialized agents (own workspace + tool restrictions): - code-formatter (GLM, read+write) - security-scanner (Opus, fallback Sonnet, read+exec) - test-coverage (GLM, read+exec) - docs-checker (Sonnet, fallback GLM, read-only)
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="config/openclaw/openclaw.tpl.json">
<violation number="1" location="config/openclaw/openclaw.tpl.json:208">
P1: Broadcasting agents with exec permissions to a WhatsApp group exposes command execution to all group messages. Restrict exec-enabled tools or remove these agents from the broadcast group to avoid remote command execution from untrusted input.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| "primary": "cliproxy/__CLAUDE_OPUS__", | ||
| "fallbacks": ["cliproxy/__GLM__"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } |
There was a problem hiding this comment.
P1: Broadcasting agents with exec permissions to a WhatsApp group exposes command execution to all group messages. Restrict exec-enabled tools or remove these agents from the broadcast group to avoid remote command execution from untrusted input.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At config/openclaw/openclaw.tpl.json, line 208:
<comment>Broadcasting agents with exec permissions to a WhatsApp group exposes command execution to all group messages. Restrict exec-enabled tools or remove these agents from the broadcast group to avoid remote command execution from untrusted input.</comment>
<file context>
@@ -198,39 +198,106 @@
+ "primary": "cliproxy/__CLAUDE_OPUS__",
+ "fallbacks": ["cliproxy/__GLM__"]
+ },
+ "tools": { "allow": ["read", "exec"] }
+ },
+ {
</file context>
| "tools": { "allow": ["read", "exec"] } | |
| "tools": { "allow": ["read"] } |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@config/openclaw/openclaw.template.json`:
- Around line 220-228: The agent entries that set model.primary to
"cliproxy/glm-4.7" (e.g., the agent with id "code-reviewer-glm" and the agents
"code-formatter" and "test-coverage") must include an explicit
non-self-referential fallback to avoid single-point failure; update each agent's
model block to add a fallbacks array containing a different model (e.g.,
"sonnet/*" or "haiku/*") rather than repeating the primary, ensuring you add the
fallbacks key alongside primary in the agent objects so that a healthy fallback
is available if glm is unreachable.
- Around line 200-248: Multiple code-reviewer agents (ids: code-reviewer-opus,
code-reviewer-sonnet, code-reviewer-glm, code-reviewer-gpt-codex,
code-reviewer-gemini) currently share the same workspace
"__HOME__/agents/code-review" causing concurrent file conflicts; update each
agent's "workspace" value to its own unique directory (for example
"__HOME__/agents/code-review/opus", ".../sonnet", ".../glm", ".../gpt-codex",
".../gemini") so that each agent runs in an isolated workspace while keeping
their other settings (model, tools) unchanged.
In `@config/openclaw/openclaw.tpl.json`:
- Around line 200-248: All five code-reviewer agent entries (code-reviewer-opus,
code-reviewer-sonnet, code-reviewer-glm, code-reviewer-gpt-codex,
code-reviewer-gemini) currently share the same workspace
"__HOME__/agents/code-review"; update each agent's "workspace" value to a unique
workspace (e.g., "__HOME__/agents/code-review-opus",
"__HOME__/agents/code-review-sonnet", etc.) so each parallel reviewer has its
own distinct workspace in the template.
| { | ||
| "id": "code-reviewer-opus", | ||
| "name": "Code Reviewer (Opus)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/claude-opus-4-6", | ||
| "fallbacks": ["cliproxy/glm-4.7"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-sonnet", | ||
| "name": "Code Reviewer (Sonnet)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/claude-sonnet-4-5-20250929", | ||
| "fallbacks": ["cliproxy/glm-4.7"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-glm", | ||
| "name": "Code Reviewer (GLM)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/glm-4.7" | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-gpt-codex", | ||
| "name": "Code Reviewer (GPT Codex)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/gpt-5.3-codex", | ||
| "fallbacks": ["cliproxy/glm-4.7"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-gemini", | ||
| "name": "Code Reviewer (Gemini Pro)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/gemini-3-pro-preview", | ||
| "fallbacks": ["cliproxy/glm-4.7"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, |
There was a problem hiding this comment.
Five code-reviewer agents share the same workspace while running in parallel — potential file conflicts.
All five code-reviewer-* agents use "workspace": "__HOME__/agents/code-review" and have exec tool access. Under the parallel broadcast strategy, they'll run concurrently in the same directory. If any agent writes intermediate files, checkouts, or scratch data to the workspace, the others may read stale or corrupted state.
Consider giving each agent a distinct workspace (e.g., __HOME__/agents/code-review/opus, .../sonnet, etc.) to ensure isolation.
Example diff for unique workspaces
{
"id": "code-reviewer-opus",
"name": "Code Reviewer (Opus)",
- "workspace": "__HOME__/agents/code-review",
+ "workspace": "__HOME__/agents/code-review/opus",
...
},
{
"id": "code-reviewer-sonnet",
"name": "Code Reviewer (Sonnet)",
- "workspace": "__HOME__/agents/code-review",
+ "workspace": "__HOME__/agents/code-review/sonnet",
...
},Apply the same pattern for glm, gpt-codex, and gemini.
🤖 Prompt for AI Agents
In `@config/openclaw/openclaw.template.json` around lines 200 - 248, Multiple
code-reviewer agents (ids: code-reviewer-opus, code-reviewer-sonnet,
code-reviewer-glm, code-reviewer-gpt-codex, code-reviewer-gemini) currently
share the same workspace "__HOME__/agents/code-review" causing concurrent file
conflicts; update each agent's "workspace" value to its own unique directory
(for example "__HOME__/agents/code-review/opus", ".../sonnet", ".../glm",
".../gpt-codex", ".../gemini") so that each agent runs in an isolated workspace
while keeping their other settings (model, tools) unchanged.
| { | ||
| "id": "code-reviewer-glm", | ||
| "name": "Code Reviewer (GLM)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/glm-4.7" | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, |
There was a problem hiding this comment.
GLM-as-primary agents have no fallback — if GLM is down, these agents fail outright.
code-reviewer-glm, code-formatter, and test-coverage all set cliproxy/glm-4.7 as primary without specifying fallbacks. Depending on how OpenClaw merges partial model overrides with agents.defaults.model:
- Deep merge: inherits
fallbacks: ["cliproxy/glm-4.7"]from defaults — self-referential and useless. - Shallow replace: loses fallbacks entirely.
Add an explicit non-self-referential fallback (e.g., Sonnet or Haiku) for these agents.
Example fix for code-reviewer-glm
{
"id": "code-reviewer-glm",
"name": "Code Reviewer (GLM)",
"workspace": "__HOME__/agents/code-review",
"model": {
- "primary": "cliproxy/glm-4.7"
+ "primary": "cliproxy/glm-4.7",
+ "fallbacks": ["cliproxy/claude-sonnet-4-5-20250929"]
},
"tools": { "allow": ["read", "exec"] }
},Apply similarly to code-formatter and test-coverage.
Also applies to: 249-257, 268-276
🤖 Prompt for AI Agents
In `@config/openclaw/openclaw.template.json` around lines 220 - 228, The agent
entries that set model.primary to "cliproxy/glm-4.7" (e.g., the agent with id
"code-reviewer-glm" and the agents "code-formatter" and "test-coverage") must
include an explicit non-self-referential fallback to avoid single-point failure;
update each agent's model block to add a fallbacks array containing a different
model (e.g., "sonnet/*" or "haiku/*") rather than repeating the primary,
ensuring you add the fallbacks key alongside primary in the agent objects so
that a healthy fallback is available if glm is unreachable.
| { | ||
| "id": "code-reviewer-opus", | ||
| "name": "Code Reviewer (Opus)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/__CLAUDE_OPUS__", | ||
| "fallbacks": ["cliproxy/__GLM__"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-sonnet", | ||
| "name": "Code Reviewer (Sonnet)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/__CLAUDE_SONNET__", | ||
| "fallbacks": ["cliproxy/__GLM__"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-glm", | ||
| "name": "Code Reviewer (GLM)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/__GLM__" | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-gpt-codex", | ||
| "name": "Code Reviewer (GPT Codex)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/__GPT_CODEX__", | ||
| "fallbacks": ["cliproxy/__GLM__"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, | ||
| { | ||
| "id": "code-reviewer-gemini", | ||
| "name": "Code Reviewer (Gemini Pro)", | ||
| "workspace": "__HOME__/agents/code-review", | ||
| "model": { | ||
| "primary": "cliproxy/__GEMINI_PRO__", | ||
| "fallbacks": ["cliproxy/__GLM__"] | ||
| }, | ||
| "tools": { "allow": ["read", "exec"] } | ||
| }, |
There was a problem hiding this comment.
Same shared-workspace concern applies here — give each parallel code-reviewer a distinct workspace.
All five code-reviewer-* agents point to __HOME__/agents/code-review. Since this is the template source and the generated openclaw.template.json mirrors it, the fix should be applied here. See the corresponding comment on openclaw.template.json for details.
🤖 Prompt for AI Agents
In `@config/openclaw/openclaw.tpl.json` around lines 200 - 248, All five
code-reviewer agent entries (code-reviewer-opus, code-reviewer-sonnet,
code-reviewer-glm, code-reviewer-gpt-codex, code-reviewer-gemini) currently
share the same workspace "__HOME__/agents/code-review"; update each agent's
"workspace" value to a unique workspace (e.g.,
"__HOME__/agents/code-review-opus", "__HOME__/agents/code-review-sonnet", etc.)
so each parallel reviewer has its own distinct workspace in the template.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@config/openclaw/openclaw.template.json`:
- Around line 282-295: The code-formatter agent currently has "write" tool
permission while the run strategy is "parallel", which risks concurrent file
mutation; locate the "code-formatter" block (and the duplicate block later) and
either remove the "write" permission from its "tools.allow" list so it becomes
read-only, or change its execution to run sequentially (move it out of the
"parallel" group or set the strategy for that agent to run after reviewers), or
give it an isolated workspace by changing "workspace" to a dedicated copy (e.g.,
a formatter-only workspace) so its writes do not affect other agents
(code-reviewers, security-scanner, test-coverage, docs-checker).
In `@config/openclaw/openclaw.tpl.json`:
- Around line 282-295: The "code-formatter" agent entry (id "code-formatter",
workspace "__HOME__/agents/formatter") grants "write" while running in parallel
with read/exec agents, causing file-mutation races; fix by changing its
configuration to either (A) run sequentially after all read-only agents
(sequence/ordering flag or move to a post-processing stage), or (B) switch its
"workspace" to an isolated copy and remove/limit "write" access in the shared
workspace so it only writes to the isolated workspace; apply the same change to
the other occurrence noted (the block around the second instance).
| { | ||
| "id": "code-formatter", | ||
| "name": "Code Formatter", | ||
| "workspace": "__HOME__/agents/formatter", | ||
| "model": { | ||
| "primary": "cliproxy/glm-4.7" | ||
| }, | ||
| "tools": { | ||
| "allow": [ | ||
| "read", | ||
| "write" | ||
| ] | ||
| } | ||
| }, |
There was a problem hiding this comment.
code-formatter has write tool permission while running in parallel with 8 other agents — risk of concurrent file mutation.
code-formatter is the only broadcast agent with "write" tool access (line 292). Under the parallel strategy, it can modify files while the other agents (code-reviewers, security-scanner, test-coverage, docs-checker) are simultaneously reading or executing against the same codebase. This can cause the other agents to read partially-written or inconsistent file state.
Consider either:
- Running
code-formattersequentially (after reviewers finish), or - Giving it a dedicated workspace copy so writes don't affect the others.
Also applies to: 345-358
🤖 Prompt for AI Agents
In `@config/openclaw/openclaw.template.json` around lines 282 - 295, The
code-formatter agent currently has "write" tool permission while the run
strategy is "parallel", which risks concurrent file mutation; locate the
"code-formatter" block (and the duplicate block later) and either remove the
"write" permission from its "tools.allow" list so it becomes read-only, or
change its execution to run sequentially (move it out of the "parallel" group or
set the strategy for that agent to run after reviewers), or give it an isolated
workspace by changing "workspace" to a dedicated copy (e.g., a formatter-only
workspace) so its writes do not affect other agents (code-reviewers,
security-scanner, test-coverage, docs-checker).
| { | ||
| "id": "code-formatter", | ||
| "name": "Code Formatter", | ||
| "workspace": "__HOME__/agents/formatter", | ||
| "model": { | ||
| "primary": "cliproxy/__GLM__" | ||
| }, | ||
| "tools": { | ||
| "allow": [ | ||
| "read", | ||
| "write" | ||
| ] | ||
| } | ||
| }, |
There was a problem hiding this comment.
code-formatter with write permission runs in parallel with all other read/exec agents — file mutation race.
This agent can modify files while 8 other agents concurrently read or exec against the same codebase. Either sequence code-formatter to run after the read-only agents, or isolate its writes to a separate workspace copy.
Also applies to: 345-358
🤖 Prompt for AI Agents
In `@config/openclaw/openclaw.tpl.json` around lines 282 - 295, The
"code-formatter" agent entry (id "code-formatter", workspace
"__HOME__/agents/formatter") grants "write" while running in parallel with
read/exec agents, causing file-mutation races; fix by changing its configuration
to either (A) run sequentially after all read-only agents (sequence/ordering
flag or move to a post-processing stage), or (B) switch its "workspace" to an
isolated copy and remove/limit "write" access in the shared workspace so it only
writes to the isolated workspace; apply the same change to the other occurrence
noted (the block around the second instance).
Summary
sonnetandglmagents toagents.listalongsidemainbroadcastsection withparallelstrategy targeting WhatsApp group120363425572081403@g.usDetails
*is not supported)Test plan
llm-update.shregeneratesopenclaw.template.jsoncorrectlymake formatpasses cleanlySummary by cubic
Enable parallel multi-model replies in the Code Review WhatsApp group (120363425148909388@g.us) using a broadcast strategy. Nine agents now respond to every message (5 reviewers + 4 specialists), and the config is formatted for nix with the ack reaction emoji set to 👀.
Written for commit ac3981e. Summary will update on new commits.