OpenClaw Enables the Operator Terminal by Default on Main

OpenClaw merged an intentional security-posture change into main on 25 July: the Gateway operator terminal is now enabled when gateway.terminal.enabled is absent. Operators who do not want an admin-scoped host PTY exposed through the Control UI must set an explicit opt-out before adopting a containing build.

This is not a vulnerability disclosure. The terminal remains restricted to operator.admin, and fully sandboxed agents remain refused. It is nevertheless a material upgrade change because an omitted key now means enabled, where it previously meant disabled.

The change is merged to main; confirm the exact release or source revision you deploy. Do not assume an installed package has the new default merely because the pull request is merged.

The action

If browser-based host terminal access is not part of your operating model, set:

gateway:
  terminal:
    enabled: false

Apply that through OpenClaw’s supported configuration workflow, validate the resulting config and verify after restart that terminal affordances are absent for administrators.

If you intend to keep the terminal enabled, treat every operator.admin credential and paired admin browser as host-control authority. Review who has that scope, how the Control UI is exposed, where pairing state is stored and whether your incident response can revoke access quickly.

What changed

Before PR #113888, terminal buttons appeared only when gateway.terminal.enabled: true was set. The flag was disabled by default and buried in Gateway settings, so upstream found the feature effectively undiscoverable even on its own hosted deployment.

The merged policy reverses the default:

• no gateway.terminal.enabled key means enabled;
• gateway.terminal.enabled: false is the opt-out;
• admin users gain Control UI and mobile terminal affordances; and
• the served Control UI includes the terminal’s required wasm-unsafe-eval Content Security Policy relaxation when enabled.

Upstream explicitly records this as a conscious product decision, not an accidental fallback. No migration writes the key for existing installations; the changed default itself is the upgrade behaviour.

What still limits access

The terminal is not presented as an anonymous shell. According to the merged implementation and its tests:

• the connection must hold operator.admin;
• non-admin scopes do not see the feature;
• fully sandboxed agents using sandbox.mode: "all" remain refused;
• unknown-agent and restart-pending revocation paths remain covered; and
• setting gateway.terminal.enabled: false disables the surface.

Those controls matter, but they do not make the default flip immaterial. operator.admin already permits powerful Gateway operations such as configuration changes and exec-approval administration. The terminal makes that authority more direct: compromise or mistaken delegation can become an interactive host session rather than a sequence of control-plane actions.

Interpretation: the right question is not “is the terminal protected?” It is “does every principal holding admin authority belong inside the host shell trust boundary?” If the answer is no, scope reduction or the explicit opt-out is required.

Upgrade acceptance checklist

If opting out

1. Add gateway.terminal.enabled: false before installing a containing build.
2. Validate configuration using the supported OpenClaw command for your release.
3. Restart the Gateway during a controlled window.
4. Confirm terminal buttons are absent from desktop and mobile Control UI surfaces.
5. Attempt no policy bypass; verify only through authorized admin and non-admin test accounts.
6. Recheck the served Control UI security headers and retain the pre-upgrade configuration for rollback.

If keeping it enabled

1. Inventory all users, devices, tokens and automations with operator.admin.
2. Remove stale admin grants and revoke lost or unmanaged devices.
3. Keep the Control UI behind the intended network and authentication boundary; do not expose it casually because the terminal is “already admin-only.”
4. Confirm fully sandboxed agents cannot open the PTY and that non-admin accounts see no terminal surface.
5. Exercise session termination and credential revocation so responders know how to close a suspected shell.
6. Monitor terminal launches and admin pairing events using the observability available in your deployment.

Do not weaken sandboxing merely to make the terminal appear. If an agent must remain fully sandboxed, the refusal is a control, not a setup error.

Evidence and limits

Upstream reports a live isolated Gateway check on the pull-request head. With no terminal key, the served Control UI advertised terminal enablement and included the required CSP directive; with enabled: false, it advertised the disabled state. Six focused Gateway suites passed, including terminal launch, Control UI, CSP and configuration reload coverage.

The pull request also records that automated reviews flagged the default flip itself as high impact and that the maintainer consciously accepted the trade-off. That is useful evidence of intent, not proof that every deployment should accept the same trade-off.

OpenClaw Academy reviewed the official merged pull request and commit chronology captured by its collector. We did not expose a production Gateway, open a real browser PTY or independently test privilege escalation. The access-control claims and tests above are attributed to upstream; the threat-model and rollout guidance is our interpretation.

Bottom line

Default-on is reasonable for discoverability only if your operator.admin boundary already matches your host-shell boundary. Many deployments will decide that it does; others absolutely should not.

Make that decision before the upgrade makes it for you. Set gateway.terminal.enabled: false if browser PTY access is unnecessary, or tighten admin access and test revocation if you keep it enabled.