openclaw - 💡(How to fix) Fix [Feature]: Expose channel user identity (SenderId) to skill/tool execution environment [1 comments, 2 participants]

Summary

Allow plugins/skills to access the channel user's identity (SenderId) during tool/script execution, so downstream APIs can identify which user triggered the action.

Problem to solve

When OpenClaw calls external company APIs on behalf of a user (via skills or tools that execute shell scripts), the downstream service has no way to know which channel user initiated the request. This blocks common enterprise requirements like:

• Per-user audit logging on the API side
• User-level rate limiting or access control
• Compliance tracing (who triggered what action, when)

Currently, SenderId exists in MsgContext for routing/auth/templating, but it is not passed into the exec environment. The before_tool_call hook only allows modifying tool parameters, not injecting environment variables. There is no plugin-level extension point to bridge this gap.

Proposed solution

Expose the channel user identity as an environment variable (e.g. OPENCLAW_SENDER_ID, OPENCLAW_CHANNEL_ID, OPENCLAW_CHANNEL_TYPE) during tool/skill shell execution. Possible implementation paths:

1. Extend before_tool_call hook result — add an optional env?: Record<string, string> field to PluginHookBeforeToolCallResult, merged into the exec environment in bash-tools.exec.ts.
2. New dedicated hook (e.g. exec_env_provider) — fires during environment construction in the exec pipeline, allowing plugins to contribute env vars based on the current message context.
3. Built-in injection — core automatically injects a set of OPENCLAW_* identity env vars when MsgContext is available, with an opt-in config flag for security.

Preferred: option 1 or 2, as they keep the mechanism plugin-driven and opt-in.

Alternatives considered

• Template interpolation in skill commands — only works for skills that support templates; doesn't cover arbitrary shell scripts or MCP tool calls.
• Passing via tool parameters — requires each tool to explicitly declare and forward the user ID; not scalable and breaks existing tools.
• Reading from a file/socket at runtime — fragile, race-prone, and breaks the stateless exec model.

Impact

• Affected: Any enterprise deployment where OpenClaw calls internal APIs that require user attribution
• Severity: Blocks workflow — without this, companies cannot meet audit/compliance requirements when using OpenClaw as an agent gateway
• Frequency: Every skill/tool invocation that hits an authenticated company API
• Consequence: Teams must build custom forks or workarounds to inject identity, or abandon OpenClaw for this use case entirely

Evidence/examples

• The exec environment is built in src/agents/bash-tools.exec.ts (lines ~1509-1579) with no plugin hook.
• before_tool_call hook (src/plugins/hooks.ts, lines ~778-811) only exposes params modification, not env.
• MsgContext.SenderId is available at the routing layer (src/auto-reply/templating.ts) but never flows into exec.

Additional information

• Must respect the existing security model — env injection should be opt-in and auditable.
• Should not break sandboxed execution or leak identity to tools that don't need it.
• Consider allowing plugins to declare which env vars they inject (manifest-level declaration for transparency).