feat(shell): cc y oc arrancan en bypass/auto por defecto (absorber ccb/ocb) #42

Activity

1. barbatdev

   added

   enhancementNew feature or requestNew feature or request

   on Jul 17, 2026
2. barbatdev commented on Oct 17, 2026

   

   barbatdev

   on Oct 17, 2026

   OwnerAuthor

   More actions

   Fleet issue review (glm)

   Recommendation: needs work

   The verified context is excellent — bypassPermissions is blocked on the account (silently degrades to dontAsk), dontAsk denies rather than streamlines, OpenCode's --auto respects explicit denies and is the correct equivalent, and cortex hooks still bite under bypass (a real DROP TABLE was cut) — but the issue has no acceptance criteria at all, and it carries an explicit open implementation decision: what happens to ccb/ocb (delete them or repurpose them as the safe variant). The local fix (OPENCODE_DEFAULT_FLAGS="--auto" in config/env.zsh) is correctly identified as needing to become a repo default in zsh/scripts/claude-helpers.zsh. Define the ccb/ocb end state and a short criteria list (cc/oc defaults, safe variant escape hatch, hooks still enforced under bypass) and this is ready.

   Item	Pass	Evidence
   clear problem	yes	Concrete and verified on 2026-07-17: default launchers require remembering the b variant; the permission-mode findings (blocked bypass, restrictive dontAsk, equivalent --auto, hooks still enforced) are documented with a real enforcement example.
   acceptance criteria present and testable	no	No acceptance criteria section exists; the desired end state (cc uses --dangerously-skip-permissions, oc uses --auto) is stated only in the request text, not as verifiable criteria.
   scope bounded	yes	Two launchers in zsh/scripts/claude-helpers.zsh plus the fate of their ccb/ocb siblings; no broader scope.
   no open questions	no	The issue's own 'A decidir en la implementación' section leaves ccb/ocb's fate (delete vs repurpose as safe variant) undecided.

   Only Juan adds the status:approved label; this review is advisory.