Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

A dev session waiting on an interactive permission prompt is recorded as `crashed`, and `retry` burns the last attempt

Abierto
#727 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@pbean ya está trabajando en esto.

Desde el 27/10/2026.

  • #1005 de @pbean — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
cli, devtools

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

area:adapters area:engine bug needs-design P2

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, profile claude
  • 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

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bmad-code-org/bmad-loop

Todos los issues de bmad-code-org/bmad-loop

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.