OpenClaw Adds Slack Assistant Threads, Visible Model Fallback Alerts, Unified Async Media, and Subagent Review Gates

From Workaround Threading to Native Assistants

Slack introduced its assistant threading system as a first-party way for AI tools to handle conversations within the platform. Until now, OpenClaw's Slack integration relied on general-purpose thread handling — functional, but disconnected from Slack's native assistant primitives. That meant missing out on suggested prompts, context persistence across thread restarts, and the dedicated assistant DM experience.

The new implementation responds to assistant_thread_started and assistant_thread_context_changed events natively. Each thread gets routed to a scoped OpenClaw session with per-monitor context management. The system resolves assistant thread context by handling each field individually — channel, team, enterprise — with fallback logic that prevents losing previously cached context when Slack sends partial payloads during reconnections.

Operators see three default suggested prompts (“What can you do?”, “Summarize this channel”, “Draft a reply”) configurable through the manifest. The Slack app manifest generation now includes assistant_view feature configuration and the required assistant:write OAuth scope automatically. For teams already running OpenClaw through Slack, this is an upgrade path to Slack's richer assistant UX without changing the underlying agent configuration.

The Silent Fallback Problem

OpenClaw has supported automatic model fallback for some time: if your selected model goes down, the system switches to a configured backup and keeps responding. Useful in theory. The problem was that this transition happened completely invisibly. Users had no idea they were talking to a different model. Worse, the system could remain pinned to the fallback indefinitely without ever attempting to return to the preferred model.

The platform now displays explicit status notices for both transitions. When falling back: “Model Fallback: [fallback] (selected [primary]; [reason])”. When recovering: “Model Fallback cleared: [primary] (was [fallback])”. These appear as delivery status messages rather than model output, keeping them separate from the actual conversation and excluded from transcript accumulation, text-to-speech processing, and pending assistant content paths.

The system also introduces a recovery probe that checks the primary model every five minutes during fallback states. This balanced approach prevents a temporarily broken model from being abandoned permanently while avoiding the aggressive polling that would slow down every turn. Once the primary responds successfully, the system switches back and posts the recovery notice.

Three Media Types, One Scheduler

OpenClaw's music and video generation tools have used an asynchronous task scheduler for some time — you request a generation, it runs in the background, and the result arrives through a message-tool completion pathway when ready. Image generation, however, was still running synchronously. Request an image, wait for it inline, move on. The inconsistency meant images lacked the status tracking, duplicate guarding, and active-task prompt context that music and video had.

The platform now consolidates all three media types onto the shared async task infrastructure. Image generation gains the same lifecycle primitives: pending status, duplicate request detection, integration with the active-task prompt context system, and delivery through the message-tool mediated pathway. For users, the practical change is that image generation no longer blocks the conversation — the agent can continue discussing while the image renders, then deliver it when complete.

The unification also means a single set of monitoring and debugging tools covers all media generation instead of requiring separate instrumentation for images. Operators running media-heavy workloads get consistent observability across the entire generation pipeline.

Trust but Verify, Even Between Agents

OpenClaw's subagent system lets parent agents delegate tasks to specialized child agents. When a child finishes its work, it hands the result back to the parent with instructions about what to do next. Previously, those instructions told the parent that the work was “ready for user delivery” — implying the parent should pass it straight through to the user without further thought.

That framing created a quality gap. Parents would rubber-stamp child results even when they contained incomplete work, missed requirements, or needed follow-up actions. The new behavior reframes completed subagent work as “ready for parent review” instead. The parent agent is now explicitly instructed to review and verify the result, determine whether the original task is actually done, and continue execution or record follow-ups if additional action is required.

The change is purely in how completions are communicated to parent agents — no routing logic, registry state, or child execution behavior changed. It's a prompt-level intervention that reshapes parent behavior by changing the framing of what a completed subagent task means. Early testing shows parents producing more thorough final responses and catching gaps that previously slipped through to users.

When Security Filters Block Intentional Configuration

OpenClaw's Docker sandbox applies environment variable sanitization to prevent accidental credential leakage into containers. If a variable name looks like a secret — API_KEY, TOKEN, PASSWORD — it gets filtered out during container creation. Sensible default behavior for inherited host environment variables. Less sensible when operators explicitly configure those variables in agents.defaults.sandbox.docker.env because they need them inside the sandbox.

The fix introduces a distinction between inherited and explicit environment variables. Values deliberately configured in the sandbox environment block now bypass the sensitive-name filter entirely. Host and process environment sanitization remains unchanged — only explicitly configured values get the bypass. The implementation also adds cache invalidation for sandbox containers when environment policies change, ensuring updated credentials propagate without requiring manual container recreation.

For operators using Gemini, OpenAI, or other API keys inside sandboxed agents, this eliminates the workaround of obfuscating variable names to sneak past the filter. You can now call your API key GEMINI_API_KEY and have it arrive inside the container intact.

Documentation Changes at a Glance

The Visibility Theme

Friday's batch shares a common thread: making the invisible visible. Model fallback was silent — now it announces itself. Subagent completions were treated as final — now they're explicitly provisional. Image generation blocked without status — now it runs async with progress tracking. Credential filtering happened without feedback — now explicit configuration is honored transparently.

The Slack assistant work follows the same pattern from the opposite direction: instead of making internal behavior visible to users, it makes the platform visible to Slack's native infrastructure. Either way, the principle is the same. Systems that hide their state from the people who need to understand them create debugging nightmares. An operator watching their model fallback to GPT-3.5 without notification wastes hours investigating quality regressions. A parent agent rubber-stamping child output without review lets incomplete work reach users. A sandbox silently swallowing credentials sends operators on wild-goose chases through container logs.

These aren't glamorous features. They're the kind of work that reduces support tickets and shortens incident response times. For a platform positioning itself as production-ready infrastructure, that's exactly the right place to invest.