zai-org / zai-org/feedback

[Bug] Subagent model overrides (builtInModelOverrides) are not applied on SSH remote workspaces

Open
#519 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

priority: P2
Dominant language
No language data
Stars
22
Forks
1
PR merge metrics
No merged PRs in 30d

Description

提交前确认 · Pre-submission checklist
  • 我已搜索过现有 issue,确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
  • 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.
问题类别 · Category

模型设置 / 切换 · Model config

涉及的 Agent 框架 · Agent framework

ZCode Agent(自研)

严重程度 · Severity

影响体验 · Major (功能可用但体验受损 / works but degraded)

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

Per-agent model overrides for built-in subagents (Settings → Subagents, stored in ~/.zcode/v2/agents-state.json as builtInModelOverrides) are not applied on SSH remote workspaces. The remote subagent silently runs the session's main model instead of the configured override — same client, same session type, different subagent model on local vs remote, with no UI indication.

Related but distinct from #403 / #433 (those cover the model picker re-validation and plan listing; this one is about overrides never reaching the remote host).

复现步骤 · Steps to reproduce
  1. In Settings → Subagents, override a built-in subagent's model — e.g. general-purpose → GLM-5.3-Flash (builtInModelOverrides in ~/.zcode/v2/agents-state.json).
  2. Attach a session over SSH to a remote host.
  3. Let the session spawn subagents of that type on the remote.
期望表现 · Expected behavior

builtInModelOverrides should apply wherever the session runs — pushed to the remote agent at connect, the same way the provider registry already is (via workspace/updateProviderRegistry).

实际表现 · Actual behavior
  • On the remote, the subagent runs the session's main model. Remote rollout log (~/.zcode/cli/rollout/model-io-sess_subagent_*.jsonl on the SSH host) shows:
"model": {"modelId": "GLM-5.3", "providerId": "builtin:zai-coding-plan", "role": "subagent", "variant": "max"}

while the local agents-state.json pins general-purpose to GLM-5.3-Flash.

  • The remote agent host carries no settings of its own: its ~/.zcode/v2/ contains only certs/, tasks-index.sqlite, telemetry-state.json — no agents-state.json.
  • Some config IS pushed to the remote at connect: the provider registry, and custom agent .md definitions are file-synced to the remote's ~/.zcode/agents/. The omission is specific to per-agent model overrides.
ZCode 版本 · ZCode version

3.11.2 (desktop client and remote server component)

设备 / 系统 / 浏览器 · Device / OS / Browser

Desktop (Electron) on Arch Linux x64; remote target: Linux x64 over SSH

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

Workaround (verified): agent .md frontmatter supports an undocumented model: field, and a user-scope agent with the same name as a built-in replaces the built-in profile in the agent runtime's profile map. A user-level ~/.zcode/agents/general-purpose.md with model: <model-key> pins the model on both hosts, because those files are synced to remotes at connect.

FYI: the agent runtime also accepts frontmatter fields model, thoughtLevel, maxTurns, memory, tools, disallowedTools, skills, background, injectAgentsMd, mcpServers — all currently undocumented.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the SSH connection flow that uses workspace/updateProviderRegistry, then compare its provider-registry sync with the builtInModelOverrides data in ~/.zcode/v2/agents-state.json. Verify the remote rollout logs under ~/.zcode/cli/rollout/model-io-sess_subagent_*.jsonl and consider the fix complete when the configured override is used for remote subagents without requiring a synced agent .md file.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron, linux
Domain
desktop, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.