Skip to content

feat(turn): qualify the credential-resolved default managed flow #4427

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
huangruiteng wants to merge 2 commits into from
+627 −4
Closed

feat(turn): qualify the credential-resolved default managed flow #4427

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4f82219
feat(turn): state the managed executor credential boundary
Sep 15, 2026
5a09c24
test(turn): qualify the credential-resolved default managed flow
Sep 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 18 additions & 3 deletions docs/integrations/deepseek-harness-connector.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,7 @@ inferring it from a host id:
"executor_kind": "managed",
"credential_env": "DEEPSEEK_API_KEY",
"endpoint_env": "DEEPSEEK_BASE_URL",
"operator_credential_bound": true,
"available": true,
"unavailable_reason": null
}
Expand All @@ -109,9 +110,23 @@ inferring it from a host id:
`executor_kind` names where the Turn's model work is billed and bounded:
`managed` for a host bound to an operator credential, `individual` for a host
that runs on one person's own CLI login, and `generic` for a caller-supplied
adapter command. `available` is `false` only when LoopX can prove the planned
host cannot launch here; it is `null` for executors this projection does not
probe rather than an unproven claim.
adapter command. `operator_credential_bound` is the narrower claim: it is `true`
only when the operator credential or an explicit `--dsh-runner` is configured,
so an explicitly selected `dsh` host that would fall back to whatever the dsh
home configures reports `executor_kind: managed` with
`operator_credential_bound: false` instead of claiming a credential it does not
hold. `available` is `false` only when LoopX can prove the planned host cannot
launch here; it is `null` for executors this projection does not probe rather
than an unproven claim.

The credential-resolved default is the flow an operator uses without naming a
host: `loopx turn run-once --goal-id <goal> --agent-id <agent> --project <dir>`
starts the managed `dsh` Turn when an operator credential is configured, and
stays on the individual `codex-cli` host when none is. `--host` still wins when
a caller needs another executor. `examples/loopx-turn-managed-default-flow-smoke.py`
qualifies exactly that default flow end to end against a local mock model
endpoint, including the readback and the fail-closed managed-runtime case, and
consumes no operator key or individual CLI subscription.

A `run-once --execute` whose planned host reports `available: false` fails
closed: it reports the status `unavailable` with the typed
Expand Down
Loading