Skip to content

Non-interactive run: an auto-rejected tool permission ends the assistant turn with no text at all #1334

Description

@anandgupta42

Summary

In a non-interactive session (altimate-code run without --yolo), when a tool call is auto-rejected because nobody can approve it, the assistant turn frequently ends with no final text at all: no answer, no partial answer from what it had already read, no "I could not run X". The process exits normally. From the user's side the command simply prints nothing.

Across 9 turns in a headless triage of the workspace pilot (v0.12.0, openai/gpt-5.6-sol, jaffle-shop dbt project linked to a workspace), every turn that contained an auto-rejected bash call ended silently; every turn without one produced a complete answer.

Reproduction

cd <a dbt project>
ALTIMATE_WORKSPACE=1 altimate-code run --model openai/gpt-5.6-sol \
  "Find the models in this project that select every column instead of naming them, and tell me which one to fix first."

Transcript tail (the model had already read the model files and the team checklist):

→ Read models/marts/orders.sql [offset=1, limit=140]
→ Read models/marts/customers.sql [offset=1, limit=120]
→ Read .altimate-code/skill/_workspace/.../references/checklist.md [offset=1, limit=200]
⚙ dbt_profiles dbt Profiles: 2 connection(s)
! permission requested: bash (altimate-dbt info); auto-rejecting
✗ bash failed
Error: The user rejected permission to use this specific tool call.
! permission requested: bash (altimate-dbt columns-source --source ecom --table raw_orders); auto-rejecting
✗ bash failed
Error: The user rejected permission to use this specific tool call.
✱ Glob "package-lock.yml" in . · 1 match

and then nothing: no assistant text, exit 0. Same shape in the other cases (altimate-dbt compile --model orders, altimate-dbt children, git status --short, ls, command -v codex, codex exec --sandbox read-only …): after one to four rejections the turn ends without output. The same prompts with --yolo produce full answers.

Why it matters

  • Headless and CI use is exactly where nobody can approve, so the user sees an empty result and cannot tell whether the model failed, was cut off, or refused.
  • The model had enough on hand to answer (it had read the files); the rejection error apparently derails the loop instead of being handed back as an observation the model can work around.
  • It also hides a second problem: the model reaches for bash (altimate-dbt, git, ls) for things it has native tools for, and each of those is a permission prompt.

Suggested fix

  • On a rejected permission in non-interactive mode, the assistant turn must still end with a text response; if the loop ends on a tool error, synthesise one that says what was attempted and what was denied.
  • Return the rejection to the model as a normal tool result so it can continue with what it has (the error text already says "user rejected"), and make sure the session does not stop on it.
  • Consider surfacing the auto-reject to stderr with a non-zero exit when the turn produced no text.

Context

Found while running 20 Reddit-sourced use cases headlessly for the workspace pilot. Transcripts: ~/demos/workspace-pilot/usecases/u08.log, u09.log, u10.log, u19.log, u02.log, u15.log on Anand's machine; runner demos/workspace-pilot/usecase.sh on the workspace_learning worktree.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions