docs(acp): correct the env-var claim on builtin ACP CLI rows (#4925)

The Devin row's comment and auth hint both implied an environment variable can
configure or authenticate the agent (`DEVIN_MODEL`, "or set a Devin API key").
It cannot: the generic ACP spawn env is deny-by-default with no allowed prefixes,
and a catalog row has no `env_passthrough` of its own — only a user-configured
`acp:<slug>` agent can declare one. Verified against the real builder:

    builtin row                      -> DEVIN_MODEL forwarded: False
    acp: agent declaring it          -> DEVIN_MODEL forwarded: True

Devin is unaffected in practice because `devin auth login` writes a credential
file it reads back at spawn, so state the file-based path instead and point a
per-model setup at an `acp:<slug>` agent carrying `--model`.

Also record the constraint once in the module docstring, since it decides whether
a future vendor can be a row at all: env-var-only vendors need a user-configured
agent, disk-credential vendors work as rows.

Co-authored-by: Isaac

Signed-off-by: Dhruv Gupta <dhruv.gupta@databricks.com>
This commit is contained in:
Dhruv Gupta
2026-08-17 17:36:01 -07:00
committed by GitHub
parent 5de71a1877
commit 6d277c4fc0
+14 -5
View File
@@ -24,6 +24,14 @@ spawn-env builder. Rows own their auth and model selection (``OWN_AUTH``): no
Omnigent credential or model override is wired, so a ``/model`` pick is
rejected up front rather than silently dropped.
One consequence worth knowing before adding a row: the generic ACP spawn env is
deny-by-default and a row has no ``env_passthrough`` of its own (only a
user-configured ``acp:<slug>`` agent can declare one), so a row's CLI reaches the
agent with the base environment only. A vendor that configures or authenticates
*solely* from an environment variable therefore needs a user-configured agent
rather than a row here; a vendor that reads stored credentials from disk (Devin,
Grok's OAuth login) works as a row.
This module stays import-light (stdlib + :mod:`omnigent.harness_install_spec`)
so the registry, onboarding, and runner layers can all read it without cycles.
"""
@@ -75,10 +83,11 @@ class AcpCliHarness:
ACP_CLI_HARNESSES: dict[str, AcpCliHarness] = {
# Devin (Cognition's ``devin`` CLI) drives ``devin acp`` — its ACP stdio
# server. Ships via a curl installer (not npm) and authenticates through its
# own ``devin auth login`` (or a Devin API key); Omnigent stores no
# credential. The row runs Devin's account-default model; a builtin row can't
# carry a per-user model, so set ``DEVIN_MODEL`` to pin one (or use an
# ``acp:`` config entry with ``--model``).
# own ``devin auth login``, which writes a credential file it reads back at
# spawn; Omnigent stores nothing. The row runs Devin's account-default model:
# a row carries no per-user model, and ``DEVIN_MODEL`` cannot reach the agent
# (see the env note above), so pinning a model needs a user-configured
# ``acp:<slug>`` agent whose command passes ``--model``.
"devin": AcpCliHarness(
install=HarnessInstallSpec(
"Devin",
@@ -86,7 +95,7 @@ ACP_CLI_HARNESSES: dict[str, AcpCliHarness] = {
None,
login_args=("auth", "login"),
install_hint="curl -fsSL https://cli.devin.ai/install.sh | bash",
auth_hint="run `devin auth login` (or set a Devin API key)",
auth_hint="run `devin auth login` (Omnigent stores no Devin credential)",
),
args=("acp",),
),