fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom#28477
Merged
mukhtharcm merged 4 commits intoopenclaw:mainfrom Feb 28, 2026
Merged
Conversation
Contributor
Greptile SummaryThis PR extends the Confidence Score: 5/5
Last reviewed commit: 5f1a832 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5f1a832a46
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
src/commands/doctor-config-flow.ts
Outdated
| const groupAllowFrom = | ||
| (account.groupAllowFrom as Array<string | number> | undefined) ?? | ||
| (parent?.groupAllowFrom as Array<string | number> | undefined); | ||
| const effectiveGroupAllowFrom = groupAllowFrom ?? effectiveAllowFrom; |
There was a problem hiding this comment.
Treat empty groupAllowFrom as fallback to allowFrom
This fallback calculation diverges from runtime access control: resolveGroupAllowFromSources treats groupAllowFrom: [] as unset and falls back to allowFrom when fallback is enabled, but groupAllowFrom ?? effectiveAllowFrom treats [] as authoritative empty. In configs that intentionally leave groupAllowFrom empty while using allowFrom, openclaw doctor will incorrectly warn that all group messages are dropped, even though runtime allows them. Align this check with the same empty-array semantics used by resolveGroupAllowFromSources to avoid false diagnostics.
Useful? React with 👍 / 👎.
Contributor
Author
There was a problem hiding this comment.
Good catch — fixed in 18e717e. The doctor check now treats empty groupAllowFrom arrays as unset before falling back to allowFrom, matching the runtime's resolveGroupAllowFromSources semantics (Array.isArray(groupAllowFrom) && groupAllowFrom.length > 0 → else void 0).
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c0556bb62b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
src/commands/doctor-config-flow.ts
Outdated
| (parent?.groupPolicy as string | undefined) ?? | ||
| undefined; | ||
|
|
||
| if (groupPolicy === "allowlist") { |
There was a problem hiding this comment.
Scope empty group allowlist warning to sender-based channels
detectEmptyAllowlistPolicy now warns for every groupPolicy === "allowlist" config that lacks groupAllowFrom/allowFrom, but that assumption is not true for all providers. Discord and Slack enforce allowlist mode through guild/channel rules (isDiscordGroupAllowedByPolicy in src/discord/monitor/allow-list.ts and isSlackChannelAllowedByPolicy in src/slack/monitor/policy.ts), and their config types expose channel/guild allowlists rather than groupAllowFrom (src/config/types.discord.ts, src/config/types.slack.ts). In those valid setups, doctor will now incorrectly claim that all group messages are silently dropped and suggest the wrong remediation.
Useful? React with 👍 / 👎.
Contributor
Author
There was a problem hiding this comment.
Good catch — fixed in 358bfa3. The group allowlist check now skips Discord and Slack, which enforce group access via guild/channel config (guilds.*.channels / channels.*) rather than sender-based groupAllowFrom. A usesChannelBasedGroupAllowlist set gates the check so it only fires for channels that actually use groupAllowFrom/allowFrom (Telegram, Mattermost, Signal, iMessage, WhatsApp, extensions, etc.).
c0556bb to
18e717e
Compare
Contributor
Author
|
Fixed in 358bfa3 — the group allowlist check now skips Discord and Slack, which enforce group access via guild/channel config ( |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 358bfa3d1e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
src/commands/doctor-config-flow.ts
Outdated
| // (Discord: guilds.*.channels, Slack: channels.*). | ||
| if ( | ||
| groupPolicy === "allowlist" && | ||
| (!channelName || !usesChannelBasedGroupAllowlist.has(channelName)) |
There was a problem hiding this comment.
Skip channel-based providers in empty group allowlist warning
This condition only exempts discord and slack, so the new sender-based warning still runs for providers like Google Chat that gate groupPolicy="allowlist" through channel/space config instead of groupAllowFrom. In extensions/googlechat/src/monitor.ts:471-485, allowlisted spaces are accepted even when groupAllowFrom is empty, so openclaw doctor now incorrectly reports that all group messages will be silently dropped and suggests the wrong remediation for valid channels.googlechat.groups setups.
Useful? React with 👍 / 👎.
src/commands/doctor-config-flow.ts
Outdated
| // Match runtime semantics: resolveGroupAllowFromSources treats | ||
| // empty arrays as unset and falls back to allowFrom. | ||
| const groupAllowFrom = hasAllowFromEntries(rawGroupAllowFrom) ? rawGroupAllowFrom : undefined; | ||
| const effectiveGroupAllowFrom = groupAllowFrom ?? effectiveAllowFrom; |
There was a problem hiding this comment.
Respect iMessage no-fallback semantics for group allowlist checks
The new check always falls back from groupAllowFrom to allowFrom, but iMessage explicitly disables that fallback at runtime (src/imessage/monitor/inbound-processing.ts:145-153 passes groupAllowFromFallbackToAllowFrom: false). With groupPolicy="allowlist", empty groupAllowFrom, and non-empty allowFrom, iMessage still blocks all group messages while this doctor logic suppresses the warning, so the misconfiguration remains undiagnosed.
Useful? React with 👍 / 👎.
The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552
…urces The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom.
358bfa3 to
b0317ce
Compare
Member
|
Merged via squash.
Thanks @tonydehnke! |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b0317cec3e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } | ||
| // These channels enforce group access via channel/space config, not sender-based | ||
| // groupAllowFrom lists. | ||
| return !(channelName === "discord" || channelName === "slack" || channelName === "googlechat"); |
There was a problem hiding this comment.
Exempt Matrix and Teams from sender-list emptiness warning
This sender-based check only excludes Discord/Slack/Google Chat, so openclaw doctor now warns that all group messages are dropped for Matrix and MS Teams when groupPolicy="allowlist" and groupAllowFrom is empty, even though both runtimes allow valid group traffic via room/team-channel allowlists in that case (extensions/matrix/src/matrix/monitor/access-policy.ts:35-40, extensions/matrix/src/matrix/monitor/handler.ts:218-227, extensions/msteams/src/monitor-handler/message-handler.ts:238-254). That produces incorrect remediation guidance for legitimate configs that intentionally rely on route allowlists instead of sender lists.
Useful? React with 👍 / 👎.
Comment on lines
+1335
to
+1339
| const rawGroupAllowFrom = | ||
| (account.groupAllowFrom as Array<string | number> | undefined) ?? | ||
| (parent?.groupAllowFrom as Array<string | number> | undefined); | ||
| // Match runtime semantics: resolveGroupAllowFromSources treats | ||
| // empty arrays as unset and falls back to allowFrom. |
There was a problem hiding this comment.
Include IRC per-channel allowlists in drop-all group warning
The warning path decides emptiness from top-level groupAllowFrom (plus allowFrom fallback handling) only, but IRC also authorizes group senders through per-channel groups.<channel>.allowFrom (extensions/irc/src/inbound.ts:148-153, extensions/irc/src/policy.ts:136-152). With groupPolicy="allowlist", empty top-level groupAllowFrom, and populated per-channel allowlists, runtime still allows matching senders, so this check can incorrectly claim that all group messages will be silently dropped.
Useful? React with 👍 / 👎.
mylukin
pushed a commit
to mylukin/openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
18 tasks
18 tasks
wanjizheng
pushed a commit
to wanjizheng/openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
wanjizheng
pushed a commit
to wanjizheng/openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com> (cherry picked from commit e7ae22a)
wanjizheng
pushed a commit
to wanjizheng/openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com> (cherry picked from commit e7ae22a)
wanjizheng
pushed a commit
to wanjizheng/openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com> (cherry picked from commit e7ae22a)
ohmyskyhigh
pushed a commit
to ohmyskyhigh/openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
vincentkoc
pushed a commit
to Sid-Qin/openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
vincentkoc
pushed a commit
to rylena/rylen-openclaw
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
newtontech
pushed a commit
to newtontech/openclaw-fork
that referenced
this pull request
Feb 28, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
wanjizheng
pushed a commit
to wanjizheng/openclaw
that referenced
this pull request
Mar 1, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
wanjizheng
pushed a commit
to wanjizheng/openclaw
that referenced
this pull request
Mar 1, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
zooqueen
added a commit
to hanzoai/bot
that referenced
this pull request
Mar 1, 2026
…penclaw#28477) Cherry-pick of upstream f1bf558.
ansh
pushed a commit
to vibecode/openclaw
that referenced
this pull request
Mar 2, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
steipete
pushed a commit
to Sid-Qin/openclaw
that referenced
this pull request
Mar 2, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
safzanpirani
pushed a commit
to safzanpirani/clawdbot
that referenced
this pull request
Mar 2, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
steipete
pushed a commit
to Sid-Qin/openclaw
that referenced
this pull request
Mar 2, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
execute008
pushed a commit
to execute008/openclaw
that referenced
this pull request
Mar 2, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
dorgonman
pushed a commit
to kanohorizonia/openclaw
that referenced
this pull request
Mar 3, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
sachinkundu
pushed a commit
to sachinkundu/openclaw
that referenced
this pull request
Mar 6, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
zooqueen
added a commit
to hanzoai/bot
that referenced
this pull request
Mar 6, 2026
…penclaw#28477) Cherry-pick of upstream f1bf558.
zooqueen
pushed a commit
to hanzoai/bot
that referenced
this pull request
Mar 6, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
Mateljan1
pushed a commit
to Mateljan1/openclaw
that referenced
this pull request
Mar 7, 2026
…penclaw#28477) * fix(doctor): detect groupPolicy=allowlist with empty groupAllowFrom The existing `detectEmptyAllowlistPolicy` check only covers `dmPolicy="allowlist"` with empty `allowFrom`. After the .26 security hardening (`resolveDmGroupAccessDecision` fails closed on empty allowlists), `groupPolicy="allowlist"` without `groupAllowFrom` or `allowFrom` silently drops all group/channel messages with only a verbose-level log. Add a parallel check: when `groupPolicy` is `"allowlist"` and neither `groupAllowFrom` nor `allowFrom` has entries, surface a doctor warning with remediation steps. Closes openclaw#27552 * fix: align empty-array semantics with runtime resolveGroupAllowFromSources The runtime treats groupAllowFrom: [] as unset and falls back to allowFrom, but the doctor check used ?? which treats [] as authoritative. This caused a false warning when groupAllowFrom was explicitly empty but allowFrom had entries. Match runtime behavior: treat empty groupAllowFrom arrays as unset before falling back to allowFrom. * fix: scope group allowlist check to sender-based channels only * fix: align doctor group allowlist semantics (openclaw#28477) (thanks @tonydehnke) --------- Co-authored-by: mukhtharcm <mukhtharcm@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
openclaw doctordetectsdmPolicy="allowlist"with emptyallowFrom(added in #27892), but misses the parallel case:groupPolicy="allowlist"withoutgroupAllowFromorallowFrom. After the .26 security hardening,resolveDmGroupAccessDecisionfails closed on empty group allowlists, silently dropping all group/channel messages with only a verbose-level log.This adds a matching check to
detectEmptyAllowlistPolicysoopenclaw doctorsurfaces a clear warning with remediation steps whengroupPolicy="allowlist"has no effective group allowlist.Changes
detectEmptyAllowlistPolicyindoctor-config-flow.tsto also checkgroupPolicy="allowlist"with emptygroupAllowFrom(falling back toallowFrom)groupAllowFrom, addallowFrom, or setgroupPolicyto"open"Test plan
pnpm buildpassespnpm test -- src/commands/doctor-config-flow.test.ts— all 17 tests passpnpm test -- src/config/config.allowlist-requires-allowfrom.test.ts— all 14 tests passgroupPolicy: "allowlist"and nogroupAllowFrom; addinggroupAllowFrom: ["*"]restored message deliveryCloses #27552