[codex] add droid agent

[axisrow]

Summary

• Add droid@latest to the bundled npm CLI package list and Docker cache-busting manifests.
• Start droid daemon --remote-access as the hapi user during container startup, logging to ${HAPI_HOME}/droid-daemon.log.
• Document the Droid process and add static regression coverage for package wiring and startup behavior.

Validation

• bash -n entrypoint.sh build.sh
• python -m pytest tests/unit/test_shell_scripts.py
• python3 -m pytest tests/unit/

[axisrow]

@claude @codex review. Focus on critical issues: bugs, security vulnerabilities, logical errors, data loss risks, performance problems. Do NOT nitpick style, naming conventions, minor formatting, or subjective preferences — only flag issues that could break functionality or cause real harm in production.

[claude]

Claude finished @axisrow's task in 2m 1s —— View job

---

PR Review: Add Droid Agent

• Gather context and read changed files
• Review entrypoint.sh changes
• Review Dockerfile / cli-packages.txt changes
• Review test changes
• Post findings

---

Findings

1. Supply chain risk: unscoped npm package name — cli-packages.txt:6

Every other AI CLI tool in this repo uses a scoped npm package:

@anthropic-ai/claude-code@latest
@openai/codex@latest
@google/gemini-cli@latest
@github/copilot@latest

droid@latest has no @scope prefix. The name droid is extremely generic; there are many unrelated packages on npm using that name (android build tools wrappers, robot frameworks, etc.). If the real Droid agent is published under @droid/cli or a similar scope, this installs the wrong — potentially malicious — package. Verify the exact npm package identity before merging. Fix this →

---

2. No opt-out for remote access — entrypoint.sh:109

hapi runner defaults to disabled and requires HAPI_RUNNER_ENABLED=true to start. The droid daemon has no equivalent guard — it starts unconditionally whenever the binary is present. Since the Dockerfile installs droid unconditionally, every container instance automatically exposes a --remote-access service with no way to disable it via env var.

This is an asymmetric and potentially surprising behaviour for users who want the bundled CLI available in terminals but don't want the daemon running. Consider adding:

if [ "${DROID_DAEMON_ENABLED:-true}" != "false" ] && \
   PATH="${HAPI_RUN_PATH}" command -v droid >/dev/null 2>&1; then

Fix this →

---

3. Log file pre-created before the availability check — entrypoint.sh:107–108

touch "${DROID_DAEMON_LOG}"          # ← runs unconditionally
chown "${HAPI_USER}:${HAPI_USER}" "${DROID_DAEMON_LOG}"
if PATH=... command -v droid ...; then

When droid is not found the log file is still created as an empty artifact. This is minor but inconsistent with how other optional components are handled.

---

Not an issue: ensure_dir_owned move

The ensure_dir_owned "${HAPI_HOME}" call was correctly moved before the droid section (and removed from before hapi server). The directory is guaranteed to exist before either touch "${DROID_DAEMON_LOG}" or touch "${HAPI_SERVER_LOG}" runs. No ordering regression.

---

Summary: Two issues worth addressing before merge — verify the npm package identity (#1, critical) and add an opt-out env var for the daemon (#2, important). The log pre-creation (#3) is minor. No test logic problems found.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f4a73358a7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Gate remote Droid daemon behind opt-in config

When /home/hapi is persisted and the Droid CLI has been authenticated or registered, this starts droid daemon --remote-access on every container boot, which connects the container to Factory's relay as a remotely reachable Droid Computer. That exposes the hapi user's workspace and any configured git credentials through a new control plane even for deployments that only intended to bundle the local CLI; make this daemon opt-in via an environment variable or explicit setup step.

Useful? React with 👍 / 👎.

[axisrow]

@claude @codex review. Focus on critical issues: bugs, security vulnerabilities, logical errors, data loss risks, performance problems. Do NOT nitpick style, naming conventions, minor formatting, or subjective preferences — only flag issues that could break functionality or cause real harm in production.

Round notes:

• Verified npm package identity: npm view droid name version description bin repository homepage dist-tags --json reports droid@0.144.2, description "Factory Droid CLI - AI-powered software engineering agent", bin droid, repository Factory-AI/factory.
• Addressed the remote-access finding in b47bb3c: droid daemon --remote-access now starts only when DROID_DAEMON_ENABLED=true, with docs and .env.example updated.

[claude]

Claude finished @axisrow's task in 0s —— View job

---

I'll analyze this and get back to you.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b47bb3cdfe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Register Droid non-interactively before daemon startup

When DROID_DAEMON_ENABLED=true on a fresh /home/hapi volume, this background daemon has no way to answer Droid's first-run BYOM registration prompt. Factory's BYOM docs say droid daemon --remote-access prompts for a computer name when the machine is not registered, while the CLI reference exposes non-interactive registration as droid computer register [name] -y; because the entrypoint never registers or verifies an existing registration before starting the daemon, new containers can hang/fail before connecting to the relay. Please either register non-interactively with a configured name before this line, or fail early with a clear pre-registration requirement.

Useful? React with 👍 / 👎.

[axisrow]

@claude @codex review. Focus on critical issues: bugs, security vulnerabilities, logical errors, data loss risks, performance problems. Do NOT nitpick style, naming conventions, minor formatting, or subjective preferences — only flag issues that could break functionality or cause real harm in production.

Round notes:

• Addressed the second-round registration finding in 89c6f1f.
• DROID_DAEMON_ENABLED=true now requires DROID_COMPUTER_NAME, validates it for shell-safe non-interactive use, runs droid computer register <name> -y, and starts droid daemon --remote-access only after successful registration.
• Factory docs confirm unregistered droid daemon --remote-access prompts for a computer name, while droid computer register [name] -y skips interactive prompts.

[claude]

Claude finished @axisrow's task in 0s —— View job

---

I'll analyze this and get back to you.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 89c6f1f4ea

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use the actual Droid CLI package

In the Docker build path I checked https://registry.npmjs.org/droid/latest, and it returns 403, so this new ADD fails before the image can install any CLI tools. Factory's own CLI reference documents installing Droid via curl -fsSL https://app.factory.ai/cli | sh rather than the unscoped droid npm package, so enabling this line makes every fresh docker build fail until the Dockerfile/cli-packages.txt use the correct installer or package.

Useful? React with 👍 / 👎.

[axisrow]

HALLUCINATION: I verified the exact Docker ADD URL from this environment and it is reachable. curl -sS -D - https://registry.npmjs.org/droid/latest -o /private/tmp/droid-latest.json returned HTTP/2 200 with JSON content, and npm view droid dist-tags latest --json returned { "latest": "0.144.2" }. The package metadata also identifies droid as "Factory Droid CLI - AI-powered software engineering agent" with bin droid and repository Factory-AI/factory. The Docker ADD https://registry.npmjs.org/droid/latest ... should not be changed based on a 403 that I cannot reproduce.