Summary
When using ZCode as a headless reviewer/gate from an agent workflow, I hit a few rough edges around credential/model injection and long-running/concurrent prompt behavior.
This is not a report that ZCode itself is unavailable. Manual short zcode --prompt calls work. The issue is about making zcode-open-bridge's documented/wrapped headless path more deterministic for downstream automation.
Environment
- ZCode CLI:
0.15.0
- Platform: macOS arm64
- Node reported by
zcode doctor: v25.9.0
- Repo:
tizerluo/zcode-open-bridge
- Auth/config source:
~/.zcode/v2/config.json
Observed issues
1. Model ID handling is inconsistent
The authoritative credential helper returns the raw configured model id:
shared/credentials.py -> ZCODE_MODEL=GLM-5.2
Relevant local lines:
model_id = next(iter(models)) if models else "GLM-5.2"
return {
"ZCODE_MODEL": model_id,
...
}
But skills/zcode-bridge-guide/SKILL.md documents an explicit env wrapper that adds a zai/ prefix for builtin Z.AI providers:
m = "GLM-5.2" if "GLM-5.2" in p.get("models", {}) else next(iter(p.get("models", {})), "")
if pid.startswith("builtin:zai"):
m = f"zai/{m}"
Meanwhile zcode-agent-help capabilities --section native_cli says the env example is GLM-5.2.
This makes downstream wrappers easy to get wrong: some copy the raw shared/credentials.py behavior, others copy the guide's zai/GLM-5.2 behavior.
Request: please define one canonical model-id format for headless ZCODE_MODEL, then align:
shared/credentials.py
- embedded copies in MCP/ACP wrappers
skills/zcode-bridge-guide/SKILL.md
packages/agent-help/zcode-agent-help
2. Explicit env override is hard to use for debugging
The documented pattern is generally:
env = {**os.environ, **load_zcode_credentials()}
This means an operator cannot temporarily run:
and expect it to override config-loaded values if the wrapper injects credentials after os.environ.
That makes model/config debugging harder in agent workflows.
Request: consider an escape hatch, for example:
- let explicit
ZCODE_MODEL, ZCODE_BASE_URL, ANTHROPIC_API_KEY win when already set, or
- add a flag/env like
ZCODE_CREDS_OVERRIDE_ENV=0/1, or
- document that config always wins and provide a supported debug command to print the exact injected env without secrets.
3. Long-running/concurrent headless gates need safer rate-limit behavior
For PR-review style usage, a single headless prompt can be much heavier than a manual short prompt. The guide already notes that open prompts can spawn multiple exploration calls and hit rate limits.
In practice, agent workflows may accidentally start multiple ZCode gates concurrently. When that happens, provider-side rate limit / quota errors can surface, while the caller only sees a generic failed subprocess.
Request: consider one or more of these in the bridge wrappers/docs:
- recommend or provide a simple process-level lock for headless review calls;
- parse common provider errors such as
ProviderBusinessError, 1302, and retry-after;
- perform bounded retry/backoff where safe;
- document a recommended focused-review prompt pattern: attach evidence/diff, avoid broad exploration, and say not to spawn extra agents/tools unless necessary.
Why this matters
zcode-open-bridge is very useful as an external reviewer/tester in automated PR workflows. Those workflows need behavior that is:
- deterministic across shell/agent environments;
- easy to debug without editing config files;
- robust when several gates are scheduled close together;
- clear about whether
GLM-5.2 or zai/GLM-5.2 is the correct headless model id.
Thanks for the project. Happy to provide more local diagnostics if useful, but I intentionally omitted secrets and provider credentials from this report.
Summary
When using ZCode as a headless reviewer/gate from an agent workflow, I hit a few rough edges around credential/model injection and long-running/concurrent prompt behavior.
This is not a report that ZCode itself is unavailable. Manual short
zcode --promptcalls work. The issue is about makingzcode-open-bridge's documented/wrapped headless path more deterministic for downstream automation.Environment
0.15.0zcode doctor:v25.9.0tizerluo/zcode-open-bridge~/.zcode/v2/config.jsonObserved issues
1. Model ID handling is inconsistent
The authoritative credential helper returns the raw configured model id:
Relevant local lines:
But
skills/zcode-bridge-guide/SKILL.mddocuments an explicit env wrapper that adds azai/prefix for builtin Z.AI providers:Meanwhile
zcode-agent-help capabilities --section native_clisays the env example isGLM-5.2.This makes downstream wrappers easy to get wrong: some copy the raw
shared/credentials.pybehavior, others copy the guide'szai/GLM-5.2behavior.Request: please define one canonical model-id format for headless
ZCODE_MODEL, then align:shared/credentials.pyskills/zcode-bridge-guide/SKILL.mdpackages/agent-help/zcode-agent-help2. Explicit env override is hard to use for debugging
The documented pattern is generally:
This means an operator cannot temporarily run:
and expect it to override config-loaded values if the wrapper injects credentials after
os.environ.That makes model/config debugging harder in agent workflows.
Request: consider an escape hatch, for example:
ZCODE_MODEL,ZCODE_BASE_URL,ANTHROPIC_API_KEYwin when already set, orZCODE_CREDS_OVERRIDE_ENV=0/1, or3. Long-running/concurrent headless gates need safer rate-limit behavior
For PR-review style usage, a single headless prompt can be much heavier than a manual short prompt. The guide already notes that open prompts can spawn multiple exploration calls and hit rate limits.
In practice, agent workflows may accidentally start multiple ZCode gates concurrently. When that happens, provider-side rate limit / quota errors can surface, while the caller only sees a generic failed subprocess.
Request: consider one or more of these in the bridge wrappers/docs:
ProviderBusinessError,1302, andretry-after;Why this matters
zcode-open-bridgeis very useful as an external reviewer/tester in automated PR workflows. Those workflows need behavior that is:GLM-5.2orzai/GLM-5.2is the correct headless model id.Thanks for the project. Happy to provide more local diagnostics if useful, but I intentionally omitted secrets and provider credentials from this report.