Skip to content

feat(openclaw): add broadcast groups with multi-model agents - #817

Merged
shunkakinoki merged 5 commits into
mainfrom
feat/openclaw-broadcast-groups
Feb 15, 2026
Merged

feat(openclaw): add broadcast groups with multi-model agents#817
shunkakinoki merged 5 commits into
mainfrom
feat/openclaw-broadcast-groups

Conversation

@shunkakinoki

@shunkakinoki shunkakinoki commented Feb 15, 2026

Copy link
Copy Markdown
Owner

Summary

  • Add sonnet and glm agents to agents.list alongside main
  • Add broadcast section with parallel strategy targeting WhatsApp group 120363425572081403@g.us
  • All three models (Opus, Sonnet, GLM) now respond in parallel to every message in the broadcast group

Details

  • Uses the specific WhatsApp group JID as the broadcast peer key (wildcard * is not supported)
  • Each agent maintains separate session state and conversation history

Test plan

  • llm-update.sh regenerates openclaw.template.json correctly
  • make format passes cleanly
  • Live config updated and gateway restarted
  • Send a WhatsApp message and confirm all three models respond

Summary 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.

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).
Copilot AI review requested due to automatic review settings February 15, 2026 13:13
@mesa-dot-dev

mesa-dot-dev Bot commented Feb 15, 2026

Copy link
Copy Markdown

You do not have enough credits to review this pull request. Please purchase more credits to continue.

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @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

  • New Agent Definitions: Added 'sonnet' and 'glm' agents to the 'agents.list' in the configuration, allowing for more diverse model interactions.
  • Broadcast Group Configuration: Introduced a 'broadcast' section with a 'parallel' strategy, specifically targeting a WhatsApp group identified by its JID.
  • Multi-Model Parallel Responses: Enabled 'main', 'sonnet', and 'glm' models to respond in parallel to messages within the configured broadcast group.
Changelog
  • config/openclaw/openclaw.template.json
    • Added 'sonnet' agent definition with 'cliproxy/claude-sonnet-4-5-20250929' model.
    • Added 'glm' agent definition with 'cliproxy/glm-4.7' model.
    • Introduced a 'broadcast' configuration section for a specific WhatsApp group, setting a 'parallel' strategy for 'main', 'sonnet', and 'glm' agents.
  • config/openclaw/openclaw.tpl.json
    • Added 'sonnet' agent definition with 'cliproxy/CLAUDE_SONNET' placeholder model.
    • Added 'glm' agent definition with 'cliproxy/GLM' placeholder model.
    • Introduced a 'broadcast' configuration section for a specific WhatsApp group, setting a 'parallel' strategy for 'main', 'sonnet', and 'glm' agents.
Activity
  • Verified 'llm-update.sh' correctly regenerates 'openclaw.template.json'.
  • Confirmed 'make format' passes cleanly.
  • Updated live configuration and restarted the gateway.
  • Pending: Verification of parallel model responses in the WhatsApp group.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@coderabbitai

coderabbitai Bot commented Feb 15, 2026

Copy link
Copy Markdown
📝 Walkthrough

Summary by CodeRabbit

  • New Features
    • Added multiple new agents (code-reviewer-opus, code-reviewer-sonnet, code-reviewer-glm, code-reviewer-gpt-codex, code-reviewer-gemini, code-formatter, security-scanner, test-coverage, docs-checker).
    • Added a top-level parallel broadcast that targets a group including the new agents to deliver messages concurrently.
  • Chores
    • Updated WhatsApp acknowledgment emoji from a Unicode escape to the visible 👀 character.

Walkthrough

Adds nine agents (code-reviewers, formatter, security scanner, test-coverage, docs-checker), introduces a top-level broadcast entry with strategy: "parallel" targeting group 120363425148909388@g.us, and changes the WhatsApp ackReaction emoji to "👀".

Changes

Cohort / File(s) Summary
OpenClaw concrete config
config/openclaw/openclaw.template.json
Inserted nine new agents: code-reviewer-opus, code-reviewer-sonnet, code-reviewer-glm, code-reviewer-gpt-codex, code-reviewer-gemini, code-formatter, security-scanner, test-coverage, docs-checker (workspaces, model.primary/fallbacks, and tool permissions).
OpenClaw template
config/openclaw/openclaw.tpl.json
Same nine agents added using placeholders (e.g., __CLAUDE_OPUS__, __GLM__, __GEMINI_PRO__) and a new top-level broadcast object: strategy: "parallel" with group 120363425148909388@g.us listing those agents.
WhatsApp channel tweak
config/openclaw/openclaw.template.json, config/openclaw/openclaw.tpl.json
Changed channels.whatsapp.ackReaction.emoji from \ud83d\udc40 to the visible emoji 👀.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

Poem

🐇 I hopped through JSON, tidy and spry,
Nine new helpers now blink an eye,
Parallel voices to a group they send,
Scanners, formatters, reviewers blend,
A rabbit’s cheer for configs that tie 🥕👀

🚥 Pre-merge checks | ✅ 3 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Merge Conflict Detection ⚠️ Warning ❌ Merge conflicts detected (8 files):

⚔️ Cargo.lock (content)
⚔️ bun.lock (content)
⚔️ config/openclaw/openclaw.template.json (content)
⚔️ config/openclaw/openclaw.tpl.json (content)
⚔️ flake.lock (content)
⚔️ nix-darwin/config/homebrew.nix (content)
⚔️ scripts/llm-update.sh (content)
⚔️ spec/llm_update_spec.sh (content)

These conflicts must be resolved before merging into main.
Resolve conflicts locally and push changes to this branch.
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: adding broadcast groups with multi-model agents for code review workflows.
Description check ✅ Passed The description is well-related to the changeset, explaining the addition of multiple agents, broadcast configuration, and parallel strategy implementation.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/openclaw-broadcast-groups
⚔️ Resolve merge conflicts (beta)
  • Auto-commit resolved conflicts to branch feat/openclaw-broadcast-groups
  • Create stacked PR with resolved conflicts
  • Post resolved changes as copyable diffs in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@mesa-dot-dev

mesa-dot-dev Bot commented Feb 15, 2026

Copy link
Copy Markdown

Mesa Description

TL;DR

Enable parallel multi-model replies in OpenClaw's Code Review WhatsApp group by adding broadcast groups and new agents.

What changed?

  • Updated config/openclaw/openclaw.template.json and config/openclaw/openclaw.tpl.json to:
    • Add sonnet and glm agents to agents.list.
    • Introduce a broadcast section with a parallel strategy targeting WhatsApp group 120363425572081403@g.us.
    • Configure nine agents (five code reviewers and four specialists) to respond in parallel to every message in the broadcast group.
    • Ensure each agent maintains separate session state and conversation history.

Description generated by Mesa. Update settings

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread config/openclaw/openclaw.tpl.json Outdated
},
"broadcast": {
"strategy": "parallel",
"120363425572081403@g.us": [

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

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.

Suggested change
"120363425572081403@g.us": [
"__WHATSAPP_BROADCAST_GROUP__": [

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 (sonnet and glm) to the agents.list configuration alongside the existing main agent
  • Introduced a broadcast configuration section with parallel strategy 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.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +199 to 211
},
{
"id": "sonnet",
"model": {
"primary": "cliproxy/__CLAUDE_SONNET__"
}
},
{
"id": "glm",
"model": {
"primary": "cliproxy/__GLM__"
}
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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, sonnet inherits fallbacks: ["cliproxy/__GLM__"] (fine), but glm ends up with its own model as its fallback (useless).
  • If it's a shallow replace of the model key, 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.

Comment on lines +214 to +221
"broadcast": {
"strategy": "parallel",
"120363425572081403@g.us": [
"main",
"sonnet",
"glm"
]
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 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 set strategy: "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 interrupt behavior: interrupt is 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 -20

Repository: shunkakinoki/dotfiles

Length of output: 269


🏁 Script executed:

# Look for any OpenClaw-related code or documentation
git ls-files | grep -i openclaw | head -30

Repository: 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 -40

Repository: 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 -100

Repository: 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.
  • interrupt queue 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

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread config/openclaw/openclaw.template.json
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)

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread config/openclaw/openclaw.tpl.json Outdated
"primary": "cliproxy/__CLAUDE_OPUS__",
"fallbacks": ["cliproxy/__GLM__"]
},
"tools": { "allow": ["read", "exec"] }

@cubic-dev-ai cubic-dev-ai Bot Feb 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Suggested change
"tools": { "allow": ["read", "exec"] }
"tools": { "allow": ["read"] }
Fix with Cubic

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +200 to +248
{
"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"] }
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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.

Comment on lines +220 to +228
{
"id": "code-reviewer-glm",
"name": "Code Reviewer (GLM)",
"workspace": "__HOME__/agents/code-review",
"model": {
"primary": "cliproxy/glm-4.7"
},
"tools": { "allow": ["read", "exec"] }
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.

Comment on lines +200 to +248
{
"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"] }
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Comment on lines +282 to +295
{
"id": "code-formatter",
"name": "Code Formatter",
"workspace": "__HOME__/agents/formatter",
"model": {
"primary": "cliproxy/glm-4.7"
},
"tools": {
"allow": [
"read",
"write"
]
}
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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-formatter sequentially (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).

Comment on lines +282 to +295
{
"id": "code-formatter",
"name": "Code Formatter",
"workspace": "__HOME__/agents/formatter",
"model": {
"primary": "cliproxy/__GLM__"
},
"tools": {
"allow": [
"read",
"write"
]
}
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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).

@shunkakinoki
shunkakinoki enabled auto-merge (squash) February 15, 2026 17:14
@shunkakinoki
shunkakinoki merged commit a034838 into main Feb 15, 2026
33 checks passed
@shunkakinoki
shunkakinoki deleted the feat/openclaw-broadcast-groups branch February 15, 2026 18:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants