Skip to content

[Bug] Resuming a completed Full Access subagent resets Edit/Bash to build mode and repeatedly prompts #155

Description

@jorgitin02

提交前确认 · Pre-submission checklist

  • 我已搜索过现有 issue,确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
  • 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

工具调用 / MCP · Tool use / MCP

涉及的 Agent 框架 · Agent framework

ZCode Agent(自研)

严重程度 · Severity

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

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

When a completed subagent is resumed with SendMessage, its active tool executor evaluates Edit and Bash calls in build mode even though both the parent and child sessions are persisted as yolo (Full Access).

This causes repeated approval popups during long implementation/review sessions. Fresh/non-resumed subagents do not exhibit the problem.

This appears related to the subagent approval bridge discussed in #85, but it is not the same symptom:

复现步骤 · Steps to reproduce

  1. Set a project/session to Full Access (yolo).
  2. Launch a writable subagent such as code-worker and let it complete.
  3. During the initial run, observe that Edit, Write, and Bash execute without approval prompts.
  4. Send a follow-up instruction to the completed worker with SendMessage.
  5. Confirm that ZCode reconstructs the child with session.resumed and resumed:true.
  6. Have the resumed worker edit a new file or execute a new Bash command.
  7. An approval popup appears. After approval, the log records tool.permission.resolved with mode:"build", even though the parent and child session records both remain {"mode":"yolo"}.
  8. Repeat with another new file or command. Additional popups occur because approvals are stored as narrow command/path rules.

期望表现 · Expected behavior

A resumed subagent should preserve the effective permission mode stored on the child and inherited from the parent. If both are Full Access / yolo, resumed Edit, Write, and Bash calls should remain Full Access and should not fall back to confirmation mode.

实际表现 · Actual behavior

After the SendMessagesession.resumed boundary:

  • the persisted parent mode remains yolo;
  • the persisted child mode remains yolo;
  • permission evaluation for the resumed child reports mode:"build";
  • new edits and commands repeatedly request approval.

This makes review-and-fix workflows interrupt-driven and can produce nearly continuous approval dialogs.

ZCode 版本 · ZCode version

3.3.6 (build 3.3.6.3198); embedded CLI 0.15.2

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

macOS 26.5 (Darwin 25.5.0), Apple Silicon arm64

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

Retained-log analysis:

  • 2,023 non-resumed Edit/Write/Bash calls: 0 explicit write-tool permission resolutions.
  • 65 resumed child calls: 17 explicit permission resolutions.
  • Every affected permission event had resumed:true and mode:"build".
  • All affected parent and child session rows were still persisted as permission={"mode":"yolo"}.
  • Five different resumed code-worker children reproduced the behavior.

Same-child control:

  • Before resume: 17 Bash, 9 Edit, and 1 Write calls without approval.
  • Parent calls SendMessage after the child completes.
  • Runtime logs session.resumed with resumed:true.
  • The resumed child's next write-capable actions produce approval events evaluated as mode:"build".

Representative redacted events:

{
  "event": "session.resumed",
  "sessionId": "sess_subagent_[redacted]",
  "context": {
    "toolName": "SendMessage",
    "agentType": "code-worker",
    "resumed": true,
    "parentSessionId": "sess_[redacted]"
  }
}
{
  "event": "tool.permission.resolved",
  "sessionId": "sess_subagent_[redacted]",
  "context": {
    "querySource": "subagent",
    "toolName": "Edit",
    "agentType": "code-worker",
    "resumed": true,
    "decision": "allow",
    "mode": "build",
    "reason": "Approved for this project"
  }
}

Likely fault boundary: resumed-child runtime reconstruction does not restore the persisted permission mode and instead uses the build fallback.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions