A dev session waiting on an interactive permission prompt is recorded as `crashed`, and `retry` burns the last attempt
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
Línea de trabajo
No se nombran archivos ni pruebas. Empieza por el manejo de session-end y dev-decision, el estado existente story-awaiting-operator y el punto de entrada bmad-loop validate; reproduce el caso del prompt con cero tokens y sin crecimiento. Se considera terminado cuando el arreglo acordado evita que una espera interactiva determinista consuma un retry y verifica el comportamiento relevante de validación o transición de estado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
A dev session waiting on an interactive permission prompt is recorded as crashed, and retry burns the last attempt
Summary
When the coding CLI stops to ask the operator a permission question, the session never
produces output and never ends on its own. bmad-loop records it as session-end status=crashed
and dev-decision action=retry. The retry launches a fresh session that hits the identical
prompt, so both attempts of a story are consumed without a single line of work being done.
The story then fails for a reason that has nothing to do with the story.
This is not specific to one prompt or one CLI — it is the general case of "the pane is
waiting for a human and bmad-loop cannot tell". It happened here with Claude Code's Bypass
Permissions confirmation.
Environment
- bmad-loop 0.11.0
- adapter kind
generic, profileclaude - Claude Code 2.1.246
- tmux 3.7c, macOS (darwin 25.6.0)
scm.isolation = none,max_dev_attempts = 2,dev_stall_grace_s = 600,
session_timeout_min = 180
What happened
Story 9-1-set-up-customer-price-groups, run 20260826-114252-3da1.
Attempt 1 launched, painted Claude Code's Bypass Permissions confirmation into the pane, and
stopped there. The journal:
{"kind":"session-start","task_id":"...-dev-1","role":"dev","adapter":"claude"}
{"kind":"session-end","task_id":"...-dev-1","status":"crashed","tokens":0,"tokens_weighted":0}
{"kind":"dev-decision","attempt":1,"session_status":"crashed","action":"retry",
"reason":"dev session crashed","env_fault":false,"session_vanished":false}
{"kind":"session-start","task_id":"...-dev-2","role":"dev","adapter":"claude"}
tokens: 0 — the session produced nothing. The log for dev-1 is 1,930 bytes and its entire
content is the confirmation screen:
WARNING: Claude Code running in Bypass Permissions mode
...
❯ 1. No, exit
2. Yes, I accept
Enter to confirm · Esc to cancel
dev-2 launched and stopped at the same screen. At that point the story was at attempt 2/2:
one keystroke away from working, and one timeout away from failing permanently.
Pressing Down+Enter in the pane by hand released it. dev-2 then ran normally.
Notably, accepting did not persist: ~/.claude.json gained no bypass-acceptance key.
Every subsequent session — dev-3, the review session, every remaining story in the sprint —
would hit the same wall.
Why retry is the wrong decision here
A session that ends with tokens: 0 and a log consisting only of a menu did not crash in
any sense that a retry can fix. The failure is deterministic and environmental: the next
session will reproduce it exactly. Retrying spends the story's remaining attempt on a
guaranteed repeat.
story-awaiting-operator already exists and is the correct terminal state — it says "a
human has to do something", which is precisely true.
Suggested fixes
1. Detect an interactive prompt and route it to story-awaiting-operator.
The signal is available without parsing CLI-specific text: a session that ends with zero
tokens and a log that never grew past its first frame has not started working. That alone
justifies not retrying. A CLI-specific confirmation-screen matcher can sharpen the message,
but the token/log-growth heuristic is adapter-agnostic and catches the general case.
2. Pre-flight the coding CLI's permission mode in bmad-loop validate.
validate already reports mux availability, binary presence on PATH, hook registration and
worktree cleanliness — host facts that decide whether a run can succeed. Whether the
configured permission mode will stop for a human belongs in the same list. Catching this
before the run costs nothing; catching it after costs a story's whole attempt budget.
3. Make the permission mode an explicit profile setting, chosen against scm.isolation.
The two are coupled and currently are not. With isolation = none the agent operates
directly on the user's checkout, which is exactly where an unattended
--dangerously-skip-permissions has the least justification; with a worktree or a sandbox
it is defensible. Surfacing the mode per profile lets an operator make that trade
deliberately instead of inheriting it.
Note on alternative modes: Claude Code 2.1.246 offers --permission-mode auto, whose
classifier returns a denial to the agent as a tool error rather than blocking the session.
That is a better shape for unattended runs than an up-front confirmation. It is not a
complete answer — auto mode's default rule set includes 67 soft_deny categories, and
whether a soft denial can raise an operator prompt inside a bmad-loop pane has not been
verified here. The fixes above hold regardless of which mode an operator picks.
- Lenguaje dominante
- Python
- Estrellas
- 165
- Forks
- 69
- Merge medio
- 1 d 2 h
- PR fusionados (30 d)
- 79
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de bmad-code-org/bmad-loop
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
bmad-code-org/bmad-loop#973 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
bmad-code-org/bmad-loop#965 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
bmad-code-org/bmad-loop#835 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
bmad-code-org/bmad-loop#1004 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 49/100
bmad-code-org/bmad-loop#1002 ·
Los mantenedores suelen responder en 1 día
Todos los issues de bmad-code-org/bmad-loop
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
pydot/pydot#601 · 4 comentarios ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
letsencrypt/cp-cps#361 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
CI: startup_failure because callers grant fewer permissions than ledger-app-workflows@v1 declaresPosiblemente ocupada @maykonmichel la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
LedgerHQ/app-boilerplate-rust#227 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
linuxmint/mintupdate#1107 ·