Skip to content

ACP sessions retain stale permissions on follow-ups and queued steers #4797

Closed

Description

@brsbl

Problem

ACP sessions retain their startup permission policy and writable roots on follow-ups and queued steers. Switching from Full Access to workspace permissions can therefore leave requests automatically approved under the previous policy.

Reproduction

  1. Start an ACP conversation with Full Access.
  2. Change to workspace permissions with user-reviewed escalation.
  3. Send a follow-up, or queue a steer while a turn is active.
  4. Have the agent request an operation requiring approval under the new policy.

Actual: the session can continue applying its startup policy and writable roots.
Expected: each follow-up and queued steer uses the current permissions before its prompt is sent. A queued steer must preserve one logical turn, even if changed native permission flags require restarting the agent.

Existing implementation and evidence

Deferred implementation: #4795, branch fix/acp-permission-refresh, commit aba7f1fcfed98dfb34866b084e80e9a49ef9b3e8. Preserve this as a starting point for a future fix; it has not merged.

  • Remote regressions reproduced stale approval policy and split steer lifecycles.
  • Remote CI passed for the proposed fix, including Linux/Windows permission and single-turn lifecycle regressions.
  • Live Hermes ACP 0.18.0 follow-up verification preserved conversation memory and completed a harmless command after an in-place permission change.
  • Live queued-steer verification is incomplete: Hermes failed during cancellation with NoneType has no attribute startswith. The same failure reproduced on unchanged main, so it is separate from the proposed fix.

Completion criteria

  • Verify permission tightening and loosening on follow-ups and queued steers with a real ACP plugin.
  • Refresh the current policy and writable roots before sending each prompt.
  • Preserve the existing session when native launch settings do not change.
  • When native flags require restarting, resume when supported and explicitly report context loss otherwise.
  • Preserve one logical turn through a queued-steer restart and settle pending tool requests correctly.

Deferred because the requesting user has no ACP plugin available for acceptance testing. Resume with an ACP setup that supports the required cancellation/steer flow.

BB-Thread-ID: thr_amz5shmy85

Activity

  1. added theissue type on Oct 3, 2026
  2. added
    providersCross-provider bridges, models, login
    provider-acpBuilt-in plugin: provider-acp
    securityOperator trust, permission enforcement
    confirmed-reproBug reproduced again from a clean trusted checkout; see linked report
    on Oct 3, 2026
  3. bb-slop-cop commented on Oct 3, 2026

    @bb-slop-cop
    Contributor

    🚨 SLOP COP 🚨 · new-issue-autopilot

    • Classification: Bug · Urgent · Medium effort; providers, provider-acp, security.
    • Reproduction and root-cause report: REPRODUCED, high root-cause confidence; label confirmed-repro.
    • Root cause: ACP turn/start retains startup policy and writable roots; queued turn/steer drops current execution options, so both paths enforce obsolete permissions.
    • Test: issue 4797 permission refresh produces eight failing permission/root transitions and eight passing unchanged-setting controls in each of two clean trusted-main checkouts. Existing ACP bridge suite: 348 tests pass. The reproduction uses the real bridge and repository stdio fixture; third-party/native-restart acceptance remains unverified.
    • No PR: fixing permission enforcement crosses a permission/security boundary, explicitly excluded from this rule's simple-fix authorization.
  4. self-assigned this
    on Oct 8, 2026
  5. added a commit that references this issue on Oct 10, 2026
    fe1a02d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

confirmed-reproBug reproduced again from a clean trusted checkout; see linked reportprovider-acpBuilt-in plugin: provider-acpprovidersCross-provider bridges, models, loginsecurityOperator trust, permission enforcement

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions