acp standalone install so zed usage will resolve

[khaliqgant]

---

[devin-ai-integration]

Devin Review found 2 new potential issues.

🟡 1 issue in files not directly in the diff

🟡 relay-acp CLI hardcodes version instead of using build-time injected version (packages/acp-bridge/src/cli.ts:81-83)

The printVersion() function in packages/acp-bridge/src/cli.ts:82 hardcodes the version as 'relay-acp 0.1.0' instead of using the build-time injected process.env.AGENT_RELAY_VERSION.

Click to expand

Problem

The workflow at .github/workflows/publish.yml:253 correctly defines the version at build time:

--define="process.env.AGENT_RELAY_VERSION=\"${{ needs.build.outputs.new_version }}\""

However, the CLI doesn't use this environment variable. Instead it hardcodes:

function printVersion(): void {
  console.log('relay-acp 0.1.0');
}

Impact

Users running relay-acp --version will always see relay-acp 0.1.0 regardless of the actual release version. This makes it difficult to verify which version is installed and can cause confusion during troubleshooting.

Compare with the main CLI at src/cli/index.ts:432-441 which correctly handles this:

const VERSION: string = (() => {
  const envVersion = process.env.AGENT_RELAY_VERSION;
  if (envVersion) return envVersion;
  // fallback to package.json...
})();

Recommendation: Update printVersion() to use the build-time injected version:

function printVersion(): void {
  const version = process.env.AGENT_RELAY_VERSION || '0.1.0';
  console.log(`relay-acp ${version}`);
}

View issues and 10 additional flags in Devin Review.

[devin-ai-integration]

🔴 Command injection vulnerability via GITHUB_TOKEN in get_latest_version

The get_latest_version function uses eval with a user-controlled environment variable GITHUB_TOKEN, allowing command injection.

Click to expand

How it works

At install.sh:128-131, the code constructs an auth header and uses eval to execute it:

if [ -n "${GITHUB_TOKEN:-}" ]; then
    auth_header="-H \"Authorization: token $GITHUB_TOKEN\""
fi

VERSION=$(eval curl -fsSL $auth_header "https://api.github.com/...")

If GITHUB_TOKEN contains shell metacharacters (e.g., foo"; rm -rf /; #), the eval will interpret them as commands:

curl -fsSL -H "Authorization: token foo"; rm -rf /; # "https://..."

Impact

An attacker who can control the GITHUB_TOKEN environment variable (e.g., in a CI environment with malicious workflow, or via social engineering) could execute arbitrary commands with the privileges of the user running the install script.

Recommendation

Avoid eval and use a safer pattern:

if [ -n "${GITHUB_TOKEN:-}" ]; then
    VERSION=$(curl -fsSL -H "Authorization: token $GITHUB_TOKEN" "https://api.github.com/repos/$REPO_RELAY/releases/latest" | sed ...)
else
    VERSION=$(curl -fsSL "https://api.github.com/repos/$REPO_RELAY/releases/latest" | sed ...)
fi

Recommendation: Remove the use of eval and use conditional curl commands instead, or use an array to build arguments safely.

---

Was this helpful? React with 👍 or 👎 to provide feedback.