Summary

Signal group chats (and likely other non-forum messaging group/channel surfaces) can be used as durable, private per-project OpenClaw sessions, but they currently cannot fully simulate the main/direct chat experience because verbose/tool progress output is suppressed for ChatType === "group".

This makes /verbose on look enabled in /status, and normal slash-command replies can work, but tool-call/progress/verbose logs do not surface in the messaging group. The result is confusing when a private 1:1 group is intentionally being used as a project room/session.

User goal / product use case

I want to use messaging-platform group chats as private durable channels / project workrooms with OpenClaw:

• one Signal group per project, e.g. Loom development
• group contains only me and the OpenClaw Signal account
• each group maps to its own durable session key (agent:<agent>:signal:group:<groupId>)
• main DM stays uncluttered
• project/research/tool spam stays inside the relevant project room
• commands like /status, /verbose on, /model, /think, etc. should apply to that project-room session
• verbose mode should behave like it does in the main/direct session, including surfacing tool calls/results/progress where safe/configured

The broader goal is not Signal-specific: allow Signal/WhatsApp/iMessage/Telegram/etc. rooms to approximate first-class private OpenClaw channels when the operator intentionally configures them that way.

Observed behavior

Environment/context:

• OpenClaw: 2026.4.29 (a448042)
• Surface: Signal group chat
• Session key shape: agent:main:signal:group:<groupId>
• Current session /status showed: verbose enabled
• Config was changed to:

{
  messages: {
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

After gateway restart:

• normal assistant replies in the Signal group started surfacing ✅
• slash command/directive replies started surfacing ✅
• /status showed verbose enabled ✅
• tool/verbose progress logs still did not surface in the Signal group ❌
• the same verbose behavior does work in the main/direct Signal session ✅

Example test:

1. In Signal group, send /verbose on
2. Send a request that runs a tool/command, e.g. try running a command
3. Tool executes and final reply appears
4. No verbose/tool-call log appears in the group, despite verbose being active

This is hard to distinguish from the agent being stalled or silently replying into the session without delivery, especially during long-running tool work.

Source-level finding

While investigating locally, I found this gate in the built runtime around dispatch/tool progress behavior:

const shouldSendVerboseProgressMessages =
  !((ctx.Surface === "slack" || ctx.Provider === "slack") && ctx.ChatType !== "direct") &&
  (ctx.ChatType !== "group" || ctx.IsForum === true);

This appears to intentionally suppress verbose progress messages for ordinary group chats, only allowing them for non-group chats or forum/topic-like groups.

That default is sensible for public/shared group chats, but it blocks the private-project-room use case where a group is deliberately acting as an isolated OpenClaw session.

Why this matters

OpenClaw already has most of the primitives for this workflow:

• group sessions are isolated and durable
• group mention gating can be disabled/configured
• group final replies can be made automatic with messages.groupChat.visibleReplies = "automatic"
• slash commands/directives are session-scoped and can apply to group sessions

The missing piece is configurable verbose/progress delivery for group/channel rooms.

Without it, messaging groups are good for final answers but not good for supervising long-running project/research/coding work, because the operator loses visibility into what the agent is doing.

Proposed solution

Add an explicit config knob for verbose/tool progress delivery in group/channel rooms, defaulting to the current safe behavior.

Possible shape:

{
  messages: {
    groupChat: {
      visibleReplies: "automatic",
      verboseProgress: "off" // default: "off" | "automatic" | "whenVerbose"
    }
  }
}

Or a simpler boolean:

{
  messages: {
    groupChat: {
      verboseProgress: true
    }
  }
}

Potential semantics:

• default remains safe: no verbose/tool progress in ordinary group chats
• when enabled, group sessions with /verbose on or /verbose full send tool summaries/progress to the originating room just like direct chats
• verboseProgress should respect existing delivery controls (visibleReplies, send policy, allowlists, groupPolicy, command authorization)
• ideally support per-channel/per-group overrides, e.g.

{
  channels: {
    signal: {
      groups: {
        "<group-id>": {
          requireMention: false,
          verboseProgress: true
        }
      }
    }
  }
}

This per-group override is important because the safe default should remain conservative for real multi-human groups, while private project rooms should be able to opt in.

Suggested implementation direction

Instead of hard-coding ctx.ChatType !== "group" || ctx.IsForum === true, resolve a policy from config and context, something like:

const shouldSendVerboseProgressMessages = resolveVerboseProgressPolicy({
  cfg,
  ctx,
  channel: ctx.Provider,
  groupId: ctx.GroupId,
  accountId: ctx.AccountId,
});

Default policy can preserve existing behavior:

• direct chats: enabled when verbose is on
• forums/topics: enabled as currently
• normal group chats: disabled unless explicitly enabled
• Slack non-direct: preserve current special-case unless explicitly intended otherwise

Policy sources could include:

1. global messages.groupChat.verboseProgress
2. channel default, e.g. channels.signal.verboseProgress
3. per-group override, e.g. channels.signal.groups["<id>"].verboseProgress
4. perhaps a session directive later, but config-only is enough to solve the immediate issue

Acceptance criteria

• In a Signal group with messages.groupChat.visibleReplies = "automatic" and group verbose progress explicitly enabled:
  • /verbose on persists for that group session
  • /status shows verbose active
  • running a tool emits the same style of verbose/tool progress messages visible in the group as in direct chat
  • /verbose off stops those progress messages
• Default behavior for ordinary groups remains unchanged/safe
• Works without requiring the agent to manually summarize every tool call in the final answer
• Documentation covers private project-room setup for messaging platforms:
  • one group/channel per project
  • group session isolation
  • visibleReplies: "automatic"
  • mention gating / activation
  • verbose progress opt-in and privacy warning

Privacy/safety considerations

Verbose mode can leak tool arguments, file paths, command output, plugin diagnostics, and potentially sensitive context. This should remain opt-in for group/channel rooms.

Recommended docs warning:

Enable group verbose progress only for trusted/private rooms. In multi-person groups, verbose output may reveal internal operations or private data.

This issue is specifically about letting operators intentionally configure private messaging rooms as durable OpenClaw workspaces, not changing the safe default for public/shared groups.