Fix: run exec-form commands as container Command (agent-server CrashLoop on OpenHands V1)

[maiconfontana]

Problem

Running this runtime against OpenHands V1 (the app_server architecture, e.g. release 1.8.0) fails: every sandbox pod goes into CrashLoopBackOff and OpenHands times out with SandboxError: Sandbox failed to start within 120s.

The agent-server container logs:

openhands-agent-server: error: unrecognized arguments: /usr/local/bin/openhands-agent-server

Root cause

OpenHands V1 sends the sandbox command in exec form, e.g.:

["/usr/local/bin/openhands-agent-server", "--port", "60000"]

The official ghcr.io/openhands/agent-server image (1.27.0-python at the time of writing) has:

ENTRYPOINT ["tini", "--", "/usr/local/bin/openhands-agent-server"]

createPod puts a multi-element req.Command into the container Args while leaving the image ENTRYPOINT in place, so the effective process is:

tini -- openhands-agent-server /usr/local/bin/openhands-agent-server --port 60000

The agent-server binary receives its own path as a positional argument and aborts.

Fix

When req.Command is in exec form (starts with an absolute path), set it as the container Command so it replaces the ENTRYPOINT and runs verbatim. Existing behaviors are preserved:

• non-absolute multi-arg commands still pass as Args to the image ENTRYPOINT (e.g. a shell-wrapper entrypoint that runs update-ca-certificates then exec "$@");
• single-string commands still run via bash -c.

One file, pkg/k8s/client.go (+24 / -5).

Testing

Verified end-to-end against OpenHands 1.8.0: with this change the sandbox pod starts, openhands-agent-server serves on :60000, and the conversation advances past WAITING_FOR_SANDBOX (no more SandboxError). The current agent-server:1.27.0-python ENTRYPOINT was confirmed via the registry image config.

Thanks for building this — glad to adjust the approach if you'd prefer a different shape.