Repository navigation
Description
Problem (one or two sentences)
When read-only auto-approve is enabled, Zoo can still briefly show Approve / Reject controls for read_file asks before the auto-approval resolves. That makes the UI look inconsistent with the user's chosen settings.
Context (who is affected and when)
This affects users who enable read-only auto-approve and then run tasks that inspect multiple files in quick succession. It is most visible during fast repo exploration, where the approval controls can flash for a moment before disappearing.
Desired behavior (conceptual, not technical)
If a read-only action is going to be auto-approved, the chat UI should feel consistent from the start. Users should not see approval controls appear for a moment and then vanish.
Constraints / preferences (optional)
Keep the work broken into reviewable 1 SP slices. Match existing repo patterns by favoring focused hook/helper extraction over introducing a new reducer or state-machine pattern.
Request checklist
- I've searched existing Issues and Discussions for duplicates
- This describes a specific problem with clear context and impact
Zoo Code Task Links (optional)
Acceptance criteria (optional)
- Users with read-only auto-approve enabled do not experience a visible approval-control flash for auto-approved
read_fileasks. - The work is split into small, reviewable subtasks that each carry their own proof.
- Existing manual approval behavior remains intact.
Proposed approach (optional)
Track this work under three 1 SP subtasks:
- [ENHANCEMENT] Extract ChatView ask/footer state for approval-flow work #103 Extract
ChatViewask/footer state for approval-flow work - [ENHANCEMENT] Suppress actionable controls for already-resolved tool asks #104 Suppress actionable controls for already-resolved tool asks
- [ENHANCEMENT] Tighten Task.ask sequencing for auto-approved read-only asks #105 Tighten
Task.asksequencing for auto-approved read-only asks
Each subtask should include its own test coverage and acceptance proof.
Trade-offs / risks (optional)
The second subtask is an interim containment step, while the third addresses the root cause. Keeping them separate makes the work easier to review and test, but it means there is a temporary overlap between containment and root-cause work.
Activity