openclaw - 💡(How to fix) Fix [Feature]: Local context event bus for desktop/workflow awareness [1 participants]

Summary

Add a local-only context event bus / ingestion API that allows trusted desktop tools to send privacy-filtered workflow context into OpenClaw, so agents can use recent work state for continuity, memory, and safer task handoff.

Problem to solve

OpenClaw is strong at execution once a task is explicitly given, but it appears to lack a clean, standard way for trusted local tools to provide structured work-context signals such as active app, active window, browser tab metadata, selected text, or summarized screen state.

This creates a gap for continuity-aware workflows. A local desktop tool may know that a user spent 20 minutes researching an API in the browser, then switched to VS Code and started implementation, but there is no obvious integration point to pass that structured context into OpenClaw safely and consistently.

As a result, agents lose important state between steps and require the user to manually restate context that already exists on the local machine.

Proposed solution

Introduce a local-only context ingestion layer for trusted producers, with a small typed event model and access controls.

Example event types: • app_focus • window_change • browser_context • selected_text • context_summary

Potential behavior: • local-only by default • trusted producer registration / permission model • retention controls for recent context • agent/skill APIs to query recent context • optional subscription to context events • privacy filtering so raw screenshots are not required

Example payload: { "event_type": "browser_context", "timestamp": "2026-04-03T19:30:00Z", "source": "continuum-local", "payload": { "title": "Gemma 4: Our most capable open models to date", "url": "https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/", "summary": "User is researching Gemma 4 capabilities and likely evaluating what to build with it." } }

Example use cases: • “Resume what I was working on” • context-aware handoff from a desktop tool into OpenClaw • better continuity across research, coding, and writing sessions • ambient assistant workflows using structured summaries instead of raw screen streaming

Alternatives considered

Alternatives considered 1. Put all context directly into prompts manually. This is inconsistent, repetitive, and does not scale across sessions or tools. 2. Let each integration invent its own ad hoc context format. This leads to fragmentation and makes agent behavior harder to reason about. 3. Send raw screenshots or full screen streams. This is heavier, more privacy-sensitive, and often unnecessary when structured metadata or summaries are enough. 4. Build this entirely outside OpenClaw. Possible, but weaker, because agents and skills would still lack a standard first-class way to access trusted recent workflow context.

Impact

Affected users/systems/channels: • users running OpenClaw alongside local desktop tools • local-first / privacy-sensitive workflows • coding, research, writing, and multi-step agent workflows

Severity: • medium today, potentially high for continuity-heavy workflows

Frequency: • frequent for users who switch between apps, tabs, and tasks throughout the day

Consequence: • repeated manual restatement of context • weaker handoff between planning and execution • less useful memory/continuity behavior • extra friction in workflows that should feel seamless

In practice, this can make OpenClaw feel reactive rather than context-aware, especially for long-running or cross-application tasks.

Evidence/examples

Comparable systems increasingly distinguish between: • perception/context gathering • memory/continuity • action/execution

A clean context ingestion boundary would make OpenClaw easier to integrate with desktop continuity tools without requiring OpenClaw itself to become a full desktop-monitoring product.

Concrete example: • a local tool detects Chrome focused on technical research for 15 minutes • user switches to VS Code • the local tool emits a context_summary • OpenClaw can use that summary to scaffold the next implementation step or answer “what was I just working on?”

Additional information This request is intentionally scoped as a narrow infrastructure capability, not a request for continuous screen recording or broad surveillance behavior.

The main goal is a safe, composable interface for structured local context.

A minimal first version could be: • local-only event ingestion endpoint • typed context events • recent context query API • permission / trust controls per source

Additional information

No response