Greptile Summary

Updated to acpx 0.1.14 with enhanced configuration flexibility and noise reduction features for ACP agent messages.

Key improvements:

• Added command and expectedVersion config options in acpx plugin to support alternative builds (e.g., local development builds). Set expectedVersion: "any" to skip version checks, or provide a path to use a custom acpx binary
• Introduced deliveryMode setting (live | final_only) to control message timing - final_only buffers all output until turn completion, reducing message spam
• Added tagVisibility config to selectively hide message types (usage updates, tool calls, etc.) that create noise in threaded conversations
• Implemented repeatSuppression to deduplicate identical status messages within a turn
• Added character limits (maxOutputChars, maxSessionUpdateChars) to prevent overly long streaming outputs
• Enhanced tool message UX by enabling in-place editing for tool call updates in live mode
• Fixed Slack thread cache to enforce cap by evicting oldest entries when full
• Fixed cron cooldown field to properly omit when not configured

Implementation quality:

• Comprehensive test coverage across all new features
• Proper defensive programming with input validation and clamping
• Clean separation of concerns (delivery coordinator, projector, stream settings)
• Cross-platform path handling
• Proper timer cleanup and state management

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The changes are well-architected with comprehensive test coverage, proper defensive programming, and careful attention to edge cases. All new features are backward-compatible (defaults preserve existing behavior), state management is clean with proper cleanup, and cross-platform considerations are handled correctly. No critical bugs or logic errors were identified during review.
• No files require special attention

_{Last reviewed commit: 9b3d250}

🔒 Aisle Security Analysis

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

1. 🟠 Unvalidated acpx version spec enables untrusted package source during auto-install

Description

ensureAcpx() builds an npm install command using expectedVersion from configuration without validating that it is a safe, pinned semver.

• Input: params.expectedVersion (ultimately user/workspace-provided plugin config)
• Sink: spawnAndCollect({ command: "npm", args: ["install", ..., acpx@${installVersion}] })
• npm package specs are not limited to strict semver; they may include dist-tags, ranges, or in many npm setups non-registry sources (e.g., git+https://..., file:..., tarball URLs). Installing from such sources can execute attacker-controlled code via install scripts.
• There is no integrity pinning (lockfile) and no --ignore-scripts, so a compromised/malicious source can lead to arbitrary code execution in the plugin's environment.

Vulnerable code:

const expectedVersion = params.expectedVersion?.trim() || undefined;
const installVersion = expectedVersion ?? ACPX_PINNED_VERSION;
...
await spawnAndCollect({
  command: "npm",
  args: ["install", "--omit=dev", "--no-save", `acpx@${installVersion}`],
  cwd: pluginRoot,
});

This is especially risky if plugin configuration can be influenced by untrusted workspaces/repositories.

Recommendation

Treat the install target as data requiring strict validation.

Recommended defenses (choose based on intended product behavior):

1. Only allow strict semver versions (no ranges/tags/URLs) when auto-installing:

import semver from "semver";

function assertSafeVersion(v: string): string {
  const cleaned = semver.valid(v);
  if (!cleaned) throw new Error("expectedVersion must be a strict semver (e.g. 0.1.15)");
  return cleaned;
}

const installVersion = expectedVersion ? assertSafeVersion(expectedVersion) : ACPX_PINNED_VERSION;

2. If you must allow tags/ranges, disallow non-registry specifiers explicitly (e.g., file:, git:, http:, https:) and whitespace/newlines.

3. Consider hardening the install:

• Add --ignore-scripts if feasible (prevents install-script execution).
• Prefer installing a bundled/verified binary over network install.
• Consider verifying the installed package integrity/version against an allowlist.

Also consider defaulting allowInstall to false unless the config is explicitly trusted by the user.

2. 🟡 Arbitrary command execution via configurable acpx command override in ACPX plugin config

Description

The ACPX plugin now allows the runtime executable to be overridden via plugin configuration (command) and allows disabling version verification (expectedVersion: "any").

This is dangerous because:

• command is accepted as any non-empty string (including bare command names resolved from PATH, or relative paths resolved against the workspace directory / process.cwd()).
• The configured value is later executed via child_process.spawn() for every ACP operation (turn execution and control commands).
• Setting expectedVersion: "any" disables strict version matching, so a non-acpx binary that simply exits 0 on --help can pass health checks and then be used as the backend.

If an attacker can influence OpenClaw config (e.g., via the gateway control-plane config endpoints/UI, or by modifying the config file on disk), they can cause the gateway to execute an arbitrary local binary/script with the gateway's privileges.

Vulnerable code (configurable command resolution):

function resolveConfiguredCommand(params: { configured?: string; workspaceDir?: string }): string {
  const configured = params.configured?.trim();
  if (!configured) {
    return ACPX_BUNDLED_BIN;
  }
  if (path.isAbsolute(configured) || configured.includes(path.sep) || configured.includes("/")) {
    const baseDir = params.workspaceDir?.trim() || process.cwd();
    return path.resolve(baseDir, configured);
  }
  return configured;
}

Execution sink (example):

const child = spawnWithResolvedCommand({
  command: this.config.command,
  args,
  cwd: state.cwd,
});

Recommendation

Treat the command override as a high-risk escape hatch and add hard guardrails.

Suggested mitigations (choose one or combine):

1. Disallow bare commands and relative paths (require absolute path):

if (configured && !path.isAbsolute(configured)) {
  throw new Error("acpx.command must be an absolute path");
}

2. Restrict to a safe allowlist (e.g., bundled binary only, or absolute paths under an allowlisted directory):

const resolved = path.resolve(configured);
const allowedRoots = [ACPX_PLUGIN_ROOT /*, maybe workspaceDir */];
if (!allowedRoots.some((root) => resolved.startsWith(root + path.sep))) {
  throw new Error("acpx.command must be inside an allowed directory");
}

3. Keep version enforcement on by default and limit override values:

• Only allow expectedVersion to be a strict semver string (no npm specifiers/tags/URLs).
• Consider removing/guarding expectedVersion: "any" behind an explicit unsafe flag.

4. Operational controls:

• Mark these fields as advanced/unsafe in UI hints.
• If the product has multiple privilege tiers, ensure only the highest-privilege operators can set plugins.entries.acpx.config.command / expectedVersion.

3. 🔵 Remote GitHub tarball dependency without integrity pinning in pnpm lockfile

Description

The lockfile resolves @​whiskeysockets/libsignal-node via a remote GitHub codeload tarball URL without an integrity (SRI) hash.

• The dependency is fetched from https://codeload.github.com/.../tar.gz/<commit>.
• The commit SHA in the URL provides some immutability, but there is no cryptographic content hash recorded in the lockfile to verify the downloaded bytes.
• This increases exposure to download-of-code-without-integrity-check scenarios (e.g., network/TLS interception in hostile environments, compromised endpoint/CDN returning unexpected bytes), and reduces reproducibility guarantees compared to registry packages which include resolution.integrity.
• This dependency is pulled into production via @​whiskeysockets/baileys (a top-level dependencies entry in package.json).

Vulnerable/at-risk lock entry:

'@​whiskeysockets/libsignal-node@​https://codeload.github.com/whiskeysockets/libsignal-node/tar.gz/1c30d7d7e76a3b0aa120b04dc6a26f5a12dccf67':
  resolution: {tarball: https://codeload.github.com/whiskeysockets/libsignal-node/tar.gz/1c30d7d7e76a3b0aa120b04dc6a26f5a12dccf67}

Recommendation

Prefer dependencies that ship via the npm registry (or another registry) with an immutable resolution.integrity recorded in pnpm-lock.yaml.

Options:

1. Switch to a registry release of @​whiskeysockets/libsignal-node (if available) rather than a GitHub tarball.
2. If a registry release is not available:
   • Consider vendoring the dependency (e.g., internal mirror/artifact repository) and pin it with a checksum.
   • Enforce install-time integrity controls in CI (e.g., pnpm install --frozen-lockfile) and consider restricting/allowlisting external fetch hosts.

If you can move to a registry-published version, the lock entry should look like other packages with an integrity field, e.g.:

'@​scope/pkg@​1.2.3':
  resolution:
    integrity: sha512-... 

Analyzed PR: #30036 at commit 87ead23

_{Last updated on: 2026-03-01T20:01:33Z}

Landed via temp rebase onto main.

• Gate: pnpm lint && pnpm build && pnpm test
• Land commit: 87ead23
• Merge commit: 907c09e

Thanks @osolmaz!