For platform, security, and DevEx

Enterprise rollout guidance

dexgate is designed to start with a pilot, then expand—not “every developer, every agent, day one.” This page is the recommended adoption path for OpenClaw, Codex, and other adapters.

Product posture: free adapters on npm and paid early access pilot. Treat this as a controlled security/platform program, not a silent plugin install.

Who this is for

Individual engineers should start from Get started for free install only. Enterprise-wide enablement should follow the phases below.

What not to do on day one

Recommended phases

Stage 1 — Free evaluation (days 0–3)

Goal: Prove the free local hard gate without a licensed Dexgate runtime.

OpenClaw free quickstart Codex free quickstart

Phase 1 — Paid pilot (about 1–2 weeks)

Goal: One real governed decision (policy decision + Passport evidence) for one team.

Minimum paid setup Pricing (early access / pilot)

Phase 2 — Expand carefully

Goal: Broader use without multiplying failure modes.

What engineers will feel (set expectations)

Mode Usually still works Typically blocked / governed
Free local hard gate Adapter-specific conservative read-only defaults only (OpenClaw: read_file / list_files / search_files; Codex: read-only shell allowlist). See Compatibility. Writes/edits, apply_patch (Codex free), tests/interpreters, chaining/redirection, git push, deploy-class, unrestricted shell — no Passport
Paid governed pilot Same day-to-day work when policy allows; high-risk actions may require Passport / approval path Production-bound change without entitled policy + evidence; incorrect workspace, runtime, or credential configuration

Free mode is intentionally narrow (conservative read-only defaults). Document that clearly so engineers do not expect full day-to-day edit/test coverage free. Keep the free wall honest and the paid upgrade path obvious.

Change-management checklist (copy for your pilot kickoff)

Host permission modes

Coding agents increasingly ship org-level defaults for how often humans approve tool calls (ask, auto/classifier, always-approve). Some hosts can push those defaults fleet-wide via remote or managed settings. That layer answers: “Should the harness prompt the user?”

dexgate answers a different question: “Should this proposed action run now with proof?” Free adapters still hard-gate high-consequence tools on the laptop. Paid pilot still sends governed action requests to the Dexgate policy runtime, issues Passports on allow-with-proof, and records decisions—even when the host would have auto-approved.

Roadmap example: Grok Build is listed as ROADMAP on the compatibility matrix. When its adapter ships, the same host-permission vs Dexgate-governance distinction applies; until then, treat Grok only as an illustration of host permission modes—not as a currently supported Dexgate integration.

More on Passports: What is an Action Passport? · Supported vs roadmap adapters: Adapters and the compatibility matrix.

Roles and systems

Observe agent activity, then configure

Free mode hard-gates on each laptop. Paid pilot gives platform and security a shared stream of what agents request—allow/deny, Passport presence, gaps—recorded as decisions you can review.

In a paid pilot, treat the customer runtime dashboard as your first operations surface:

  1. Stand up the minimum licensed runtime and connect one adapter.
  2. Open the customer runtime dashboard while the pilot team uses the agent normally.
  3. Note which tools and action classes appear, what is allowed vs denied, and where evidence is missing.
  4. Only then define the managed policy set, approvals, and console deployment checks—so configuration matches real traffic.

Free evaluation has no runtime dashboard: you only get the local hard gate. Shared governed-action monitoring starts once the paid runtime is connected.

Adapter maturity (for rollout planning)

Status and coverage details are in the compatibility matrix and on Adapters.

Related docs

Start free evaluation Paid pilot setup Contact