Greptile Summary

This PR consolidates gateway auth-resolution across the Discord exec-approval monitor, node-host runner, and CLI call/probe paths into a single shared surface (src/gateway/connection-auth.ts), while also extending systemd service-audit token-drift checks to cover EnvironmentFile= entries alongside existing Environment= parsing. The changes are broad but well-scoped — they address a long-standing source of credential-resolution drift and close several related issues in one coherent diff.

Key observations:

• src/daemon/systemd.ts — inverted error-handling condition: In resolveSystemdEnvironmentFiles, the catch block contains if (!optional) { continue; }. Because there is no code after the try/catch in the inner loop body, continue and falling through the catch are behaviourally identical — all EnvironmentFile read failures are silently swallowed regardless of optionality. The condition is redundant and misleads readers into expecting different handling for optional vs. non-optional entries. If the intent is truly "always resilient", the conditional should be removed; if non-optional file failures should surface, the non-optional branch should throw rather than continue.

• Shared resolver integration in exec-approvals.ts and runner.ts is clean — both callsites now use resolveGatewayConnectionAuth with appropriate options, and the bespoke precedence logic in runner.ts has been correctly removed.

• call.ts SecretRef error wrapping (onResolveRefError) improves diagnostics by including the config-path in the error message.

• client-callsites.guard.test.ts is an effective structural guard; the allowlist approach will catch unauthorised new GatewayClient( additions in future PRs.

• Test coverage for EnvironmentFile parsing is comprehensive for the happy paths; a test validating the "non-optional file missing" resilience path would help document the intended behaviour and guard against inadvertent future changes.

Confidence Score: 4/5

• Safe to merge with one low-risk logic issue to address in resolveSystemdEnvironmentFiles.
• The PR is well-structured with good test coverage across the new auth-resolution surface. The one noteworthy issue — an inverted/redundant if (!optional) condition in resolveSystemdEnvironmentFiles — does not cause incorrect observable behaviour today (both branches silently continue), but it misleads readers and may mask a missing resilience test for non-optional missing files. All other changes (shared resolver, discord/node-host migration, call.ts diagnostics, guard test) look correct.
• src/daemon/systemd.ts — review the resolveSystemdEnvironmentFiles catch-block condition (lines 188–193).

_{Last reviewed commit: a438ebf}

🔒 Aisle Security Analysis

We found 3 potential security issue(s) in this PR:

1. 🟠 Gateway token/password leakage in node daemon status JSON via systemd EnvironmentFile parsing

Description

readSystemdServiceExecStart() now parses EnvironmentFile= and merges key/value pairs into the returned command.environment.

runNodeDaemonStatus(..., { json: true }) then serializes and prints the entire command object (including command.environment) to stdout without redaction.

This can expose secrets such as:

• OPENCLAW_GATEWAY_TOKEN
• OPENCLAW_GATEWAY_PASSWORD

If the systemd unit references an environment file containing credentials (a common pattern), openclaw node daemon status --json will output them in plaintext JSON. This is especially risky when JSON output is collected by logging/telemetry, CI artifacts, shell history capture, or shared support bundles.

Vulnerable sink (JSON output includes command unredacted):

const payload = {
  service: {
    ...buildDaemonServiceSnapshot(service, loaded),
    command,
    runtime,
  },
};

if (json) {
  defaultRuntime.log(JSON.stringify(payload, null, 2));
  return;
}

Data flow:

• input: systemd unit file content EnvironmentFile=... and env-file contents
• processing: readSystemdEnvironmentFile() reads file(s) and parses KEY=VALUE
• output sink: JSON.stringify(payload) in node daemon status prints secrets

Recommendation

Redact/whitelist service environment variables in all JSON/text outputs that include command.environment.

For example, mirror the daemon status implementation by filtering env keys before JSON output:

import { filterDaemonEnv } from "../daemon-cli/shared.js";

const safeCommand = command?.environment
  ? { ...command, environment: filterDaemonEnv(command.environment) }
  : command;

const payload = {
  service: {
    ...buildDaemonServiceSnapshot(service, loaded),
    command: safeCommand,
    runtime,
  },
};

Alternatively (more conservative): omit command.environment entirely from JSON outputs for status commands, since it can contain secrets from Environment= and EnvironmentFile=.

2. 🟠 Gateway URL override can leak persisted device-auth token (ACP server) due to missing explicit-auth enforcement

Description

The ACP gateway client accepts URL overrides but does not enforce ensureExplicitGatewayAuth (or any equivalent guard) before connecting.

As a result:

• When opts.gatewayUrl (CLI --url) or OPENCLAW_GATEWAY_URL is set, resolveGatewayConnectionAuth() may return no token/password (by design for override-safety).
• GatewayClient will still fall back to a persisted device-auth token (from loadDeviceAuthToken) whenever no explicit token is provided.
• This causes the client to transmit a valid bearer credential to whatever WSS endpoint the URL override points to (attacker-controlled in phishing/misconfig scenarios), violating the intended “override-safe” contract and enabling credential exfiltration.

Vulnerable flow:

• input: opts.gatewayUrl (CLI) or process.env.OPENCLAW_GATEWAY_URL
• sink: GatewayClient WebSocket connect handshake includes deviceToken / auth.token fallback

Vulnerable code (callsite):

const creds = await resolveGatewayConnectionAuth({
  config: cfg,
  explicitAuth: { token: opts.gatewayToken, password: opts.gatewayPassword },
  env: process.env,
  urlOverride: gatewayUrlOverrideSource ? connection.url : undefined,
  urlOverrideSource: gatewayUrlOverrideSource,
});

const gateway = new GatewayClient({
  url: connection.url,
  token: creds.token,
  password: creds.password,
  ​// deviceIdentity defaults => enables persisted device-token fallback
});

Recommendation

Enforce override-safety for long-running clients the same way callGatewayWithScopes() does.

Option A (recommended): call ensureExplicitGatewayAuth() after resolving creds and before creating/starting GatewayClient:

import { ensureExplicitGatewayAuth } from "../gateway/call.js";

const resolved = await resolveGatewayConnectionAuth({
  config: cfg,
  env: process.env,
  explicitAuth: { token: opts.gatewayToken, password: opts.gatewayPassword },
  urlOverride: gatewayUrlOverrideSource ? connection.url : undefined,
  urlOverrideSource: gatewayUrlOverrideSource,
});

ensureExplicitGatewayAuth({
  urlOverride: gatewayUrlOverrideSource ? connection.url : undefined,
  urlOverrideSource: gatewayUrlOverrideSource,
  explicitAuth: { token: opts.gatewayToken, password: opts.gatewayPassword },
  resolvedAuth: resolved,
  errorHint: "Fix: pass --token or --password",
});

Option B: add a dedicated guard in resolveGatewayConnectionAuth() that throws when an override is present but no explicit (CLI) or no env creds (env override).

Additionally, consider hardening GatewayClient so persisted device-token fallback is disabled when any explicit shared auth is present or when a URL override is in use (requires a new option like disableStoredDeviceTokenFallback).

3. 🟠 Unvalidated AgentParams.workspaceDir enables arbitrary host filesystem write/mount via gateway agent endpoint

Description

The gateway agent RPC accepts a client-supplied workspaceDir (JSON: workspaceDir) and forwards it into the agent runtime when spawnedBy is provided. This value is not validated (no allowed-root constraint, no realpath containment, no absolute-path prohibition).

As a result, an authenticated gateway client with access to the agent method can:

• Create directories and write bootstrap files in attacker-chosen locations on the host via ensureAgentWorkspace().
• Potentially cause sandbox escape / host filesystem exposure when sandbox/Docker mode is enabled, because the chosen workspace path is later used to select/mount the workspace directory.

Vulnerable call path (input → sink):

• Input: workspaceDir from RPC params
• Pass-through: src/gateway/server-methods/agent.ts forwards the value when spawnedBy is non-empty
• Sink: src/commands/agent.ts uses it as the workspace directory and calls fs.mkdir(..., { recursive: true }) and writes bootstrap files (e.g. AGENTS.md, SOUL.md, etc.).

Vulnerable code (gateway ingress):

​// Internal-only: allow workspace override for spawned subagent runs.
workspaceDir: spawnedByValue ? request.workspaceDir : undefined,

Sink (filesystem writes):

const workspaceDirRaw = opts.workspaceDir?.trim() ?? resolveAgentWorkspaceDir(cfg, sessionAgentId);
const workspace = await ensureAgentWorkspace({ dir: workspaceDirRaw, ensureBootstrapFiles: ... });

Client exposure: the Swift gateway models added workspacedir / workspaceDir, making it easier for client code to send this field.

Recommendation

Do not allow network-facing callers to choose an arbitrary host path.

Recommended mitigations (defense-in-depth):

1. Reject workspaceDir at the gateway boundary unless the request is coming from a strictly-internal/trusted callsite (not merely spawnedBy being present). For example, require an explicit internal capability/flag, or require senderIsOwner and verify spawnedBy refers to an existing session owned by the same operator.

2. Server-side path validation before use:

   • require the value to be relative to a configured workspace root, or
   • resolve with realpath and ensure it is within an allowed root (and reject roots like /).

Example (allowed-root enforcement):

import fs from "node:fs";
import path from "node:path";

function resolveWorkspaceOverrideOrThrow(input: string, allowedRoot: string): string {
  const candidate = path.resolve(input);
  const rootReal = fs.realpathSync(allowedRoot);
  const candidateReal = fs.realpathSync(candidate);
  if (!candidateReal.startsWith(rootReal + path.sep)) {
    throw new Error("workspaceDir must stay within the configured workspace root");
  }
  return candidateReal;
}

3. If the goal is “subagent inherits parent workspace”, ignore the client-provided path entirely and instead derive it from the parent session on the server (e.g., resolve the parent session’s effective workspace directory and reuse that).

Analyzed PR: #39241 at commit 7844645

_{Last updated on: 2026-03-08T01:29:43Z}