WorkIQ updates in ClawHub

[samanthamsong]

Epic: «Secure & contained node (MXC)» (#837)
Backlog Doc ID: #43 · Priority: P2 · Area: containment

Description
WorkIQ updates in ClawHub. Depends on containment; complicated by licensing and identity tokens.

Definition of done
WorkIQ runs in ClawHub with the identity/token story resolved.

Part of the «Secure & contained node (MXC)» tracking issue (#837).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 1, 2026, 12:40 PM ET / 16:40 UTC.

Summary
Keep open. Current main has generic gateway-backed skill management, MXC containment, and gateway credential primitives, but no WorkIQ implementation or approved licensing and identity-token contract. This collaborator-authored, security-sensitive feature remains a product and security decision within the open MXC program.

**Likely related people**

• samanthamsong is the likely product-direction contact as author of this request and its parent MXC tracker.
• Scott Hanselman is a likely implementation contact from the current MXC and skill-management history.

Reproducibility: not applicable. This is a proposed integration rather than a report of broken existing behavior, and current main contains no WorkIQ implementation to reproduce.

Root-cause cluster
Relationship: canonical
Canonical: #853
Summary: This issue is the specific WorkIQ child item in the broader MXC program; the parent tracks dependencies but does not replace the unresolved WorkIQ product decision.

Members:

• partial_overlap: 🦞 Tracking: Secure & contained node (MXC) #837 - The parent tracker explicitly lists this work as a child and covers the broader secure-and-contained-node outcome.
• adjacent_distinct: MXC session management (Entra Agent Sessions + WAM helper) #849 - Both items involve identity concerns under MXC, but the Entra and WAM session work is a distinct integration from WorkIQ packaging and licensing.
• adjacent_distinct: Tool containment testing + triage (camera, browser) #850 - Both are MXC-gated containment work, but default-tool containment testing is distinct from a WorkIQ ClawHub integration.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should OpenClaw support WorkIQ through ClawHub under MXC, and what licensing plus identity-token contract is authorized for that integration?	Approve a bounded WorkIQ contract: Define the package owner and license terms, token issuer and scopes, secure storage and revocation behavior, and MXC permissions before a focused implementation begins.

Why: The repository has generic skills, containment, and credential primitives, but the request does not define a permitted package, token issuer, scopes, storage model, or fallback behavior. Choosing those boundaries is a product and security decision, not a mechanical repair.

Next step
Do not dispatch an automated repair because the work requires maintainer approval of the product, licensing, identity-token, and security boundaries first.

Security
Needs attention: The requested WorkIQ identity-token and MXC execution model needs explicit security review before implementation.

Review details

Best possible solution:

Define and approve a WorkIQ package, licensing, identity-token, scope, storage, and MXC-containment contract, then implement it as a focused ClawHub integration with end-to-end sandbox and credential proof.

Do we have a high-confidence way to reproduce the issue?

Not applicable. This is a proposed integration rather than a report of broken existing behavior, and current main contains no WorkIQ implementation to reproduce.

Is this the best way to solve the issue?

Unclear until maintainers approve the licensing and identity-token model. Reusing the generic skills surface alone would not define the required token, scope, and MXC security boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Implementing an undefined WorkIQ token flow could bypass the existing device-token precedence and trusted-endpoint recovery safeguards.
• Licensing, package ownership, identity scopes, and MXC runtime permissions remain unspecified, so a generic skill installation path is not adequate authorization.

Codex review notes: model internal, reasoning high; reviewed against 8ac00c5f4977.

Label changes

Label changes:

• remove clawsweeper:needs-maintainer-review: Current issue advisory state no longer selects this label.

Label justifications:

• P2: This is a planned integration with meaningful containment and credential implications, but it is not a confirmed active regression or release-blocking failure.
• impact:security: The request explicitly depends on containment and identity tokens, which affect execution isolation and credential boundaries.
• impact:auth-provider: The unresolved identity-token story would determine authentication and provider-token handling for the integration.

Evidence reviewed

Security concerns:

• [medium] Define the WorkIQ identity-token boundary
  The request calls out identity tokens but does not specify issuer, scopes, persistence, revocation, or how it preserves the repository's device-token precedence and trusted fallback rules.
  Confidence: 0.95
• [medium] Authorize package licensing and sandbox permissions
  A licensed WorkIQ package must have an approved distribution and MXC permission model before it can use the generic skill-management path.
  Confidence: 0.9

What I checked:

• No current WorkIQ implementation: A case-insensitive current-tree search returned no WorkIQ references, so current main does not implement the requested integration. (8ac00c5f4977)
• Existing generic ClawHub skill surface: The gateway client exposes generic skill status, install, and enablement operations, while the tray page consumes generic skill fields such as id, source, description, and skillKey. Neither defines a WorkIQ-specific package, license, or identity flow. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:912, 8ac00c5f4977)
• MXC containment exists but does not settle WorkIQ policy: Current main builds against the MXC SDK and creates restrictive sandbox policies, including deny-over-allow path filtering. That provides a containment foundation, not an authorization for a licensed WorkIQ package or its tokens. (src/OpenClaw.Shared/Mxc/MxcPolicyBuilder.cs:95, 8ac00c5f4977)
• Credential policy is security-sensitive: The connection architecture requires device-token precedence and constrains fallback from device credentials to shared or bootstrap credentials. A new WorkIQ identity flow must be designed against those existing security invariants rather than added as a generic skill toggle. (docs/CONNECTION_ARCHITECTURE.md:182, 8ac00c5f4977)
• Current-area provenance: Blame attributes the active MXC policy and availability code to Scott Hanselman in commit 15ed439, which is on current main. The feature-history trail available in this checkout is limited, but it identifies the recent code-area contributor. (src/OpenClaw.Shared/Mxc/MxcPolicyBuilder.cs:95, 15ed439dc5a3)
• Maturity score unavailable: The required shortlist helper could not evaluate maturity because this checkout has no qa/maturity-scores.yaml, so no maturity label is selected.

Likely related people:

• samanthamsong: Authored this request and the open MXC tracking issue that explicitly lists this work as a child dependency. (role: program and product-direction author; confidence: medium)
• Scott Hanselman: Current MXC policy and availability code is attributed by blame to the same current-main commit, and the current generic skill-management surface is present in that area of the codebase. (role: recent MXC and skills-area contributor; confidence: medium; commits: 15ed439dc5a3; files: src/OpenClaw.Shared/Mxc/MxcPolicyBuilder.cs, src/OpenClaw.Shared/Mxc/MxcAvailability.cs, src/OpenClaw.Tray.WinUI/Pages/SkillsPage.xaml.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.