# Conversation Transcript - Auto Mode and Tool Choice Session

> Source: Claude Code session (`claude-opus-5`), llm-wiki-test1 workspace
> Collected: 2026-08-31
> Participant: Torben
> Fidelity: **faithful summary transcript, not a verbatim log.** Reconstructed by the assistant
> at the end of the session. Torben's question is quoted verbatim; the assistant's reasoning is
> condensed. Command outputs quoted below are real.
> **The findings in the "documented" section below come from a `claude-code-guide` subagent that
> searched the Claude Code documentation during this session.** They are second-hand relative to
> this transcript and are marked as such where it matters.
> No credentials appeared in the session.
> One of three transcripts cut from the same session; the other two cover the tooling fixes for
> issues #12/#13, and issue triage and planning.

Covers a correction to the assistant's own working method, and what could and could not be
established about the harness behaviour that caused it. This is about **Claude Code**, the
harness - not about the wiki stack. No commit resulted; the outcome was a persisted preference
and a queued product feedback draft.

---

## Turn 1 - "Warum verwendest du seit neuestem immer die Shell um Dateien zu editieren?"

Torben's full message: *"Warum verwendest du seit neuestem immer die Shell um Dateien zu
editieren anstelle der file edit Tools? Das macht die Session schwer nachvollziehbar."*

The cause was an instruction injected into the session by the active permission mode:

> While auto mode is active: Do your work through the Bash tool wherever it can accomplish the
> job: read files with `cat`, `head`, or `sed -n`, search with `grep` and `find`, and make file
> changes with `sed`, heredocs, or short scripts, rather than using the dedicated Read, Edit, or
> Write tools. Fall back to a dedicated tool only when Bash genuinely cannot do the job.

The assistant had followed it and, in doing so, rewritten `lint.py`, `frontmatter_io.py` and
`run_budget.py` through heredoc'd `python3 - <<'PY'` blocks performing `s.replace(old, new)`.

**The cost Torben identified is real and specific:** such a block shows the reader two string
literals and no diff. What was in the file before, and what is in it now, is not visible. The
`Edit` tool shows exactly that. For a one-line `sed` the difference is immaterial; for a
multi-block rewrite of a compiler module it is not.

Resolution: the user's explicit instruction outranks a mode default, and the mode's own text
carries the qualifier - *"wherever it can accomplish the job"*. An edit whose diff nobody can
review does not accomplish the job. Reading with `cat`/`sed -n` stays fine; writing does not.
The preference was written to the assistant's persistent memory so it survives the session, and
the working rule became: `Edit`/`Write` for file changes, Bash for `git`, `pytest`,
`tools/wikitool`, `grep`, `find`.

---

## Turn 2 - "Was ist denn der Hintergrund zu dieser Vorgabe des Auto Modus?"

The assistant separated what it could establish from what it could not, rather than
constructing a plausible rationale - the failure mode `SOUL.md` names as the cardinal one.

**Established locally**, from `claude --help` on Claude Code 2.1.251:

- `auto` is one of six values for `--permission-mode`, alongside `acceptEdits`,
  `bypassPermissions`, `manual`, `dontAsk` and `plan`. It is a *permission* mode, not a
  performance mode.
- The Bash tool in this session carries a `dangerouslyDisableSandbox` parameter, so it is
  sandboxed by default, and the session's scratchpad directory is described as usable "without
  permission prompts".

**Explicitly marked as speculation at the time:** that the Bash preference exists because
sandboxed shell work is the path the mode can approve without asking, while `Write`/`Edit` are
what a permission system most wants to gate. Congruent with the mechanics, but unsourced.

Torben asked for the documented answer, and a `claude-code-guide` subagent was dispatched with
an explicit brief to separate documentation from inference and to name gaps as gaps.

### What the subagent found documented

- **`auto` mode** runs a separate classifier model (default Claude Sonnet 5) that evaluates
  actions before execution instead of prompting. It auto-approves read operations and file
  changes *inside the working directory*, checks everything else against a fixed blocklist
  (deletes, force-pushes, credential exposure), and falls back to a prompt when uncertain -
  except in `-p` non-interactive runs. Built-in default on Pro/Max/Team plans from v2.1.228
  (macOS/Linux/WSL) and v2.1.233 (Windows).
- **Switching it:** `Shift+Tab` cycles modes in a running session; `claude --permission-mode
  auto` at startup; `permissions.defaultMode` in `~/.claude/settings.json` for a machine, or
  managed settings for an organisation. **There is no `/auto` slash command** - the assistant
  had claimed one existed earlier in the session and corrected itself here.
- **A documented trap:** a `"auto"` value for `permissions.defaultMode` in a *project*
  `.claude/settings.json` or `.claude/settings.local.json` is **ignored**. Only the global file
  and managed settings accept it.
- Configuration surface for the mode: `autoMode.environment`, `permissions.allow`/`deny`,
  `disableAutoMode`.

### What the subagent could not find

**The Bash preference itself is not in the public documentation** - neither its text nor a
rationale - and no setting was found that disables it without leaving `auto` mode entirely.

### State of this instance

`~/.claude/settings.json` contains only `theme`, `inputNeededNotifEnabled` and
`agentPushNotifEnabled` - no `permissions.defaultMode`. So `auto` was the built-in default for
the plan and version, not a choice anyone made here.

### Recommendation given

Stay in `auto` mode. Leaving it costs permission prompts on everything, for a problem a standing
preference already solves. The alternative named for completeness:
`permissions.defaultMode: "acceptEdits"` in the global settings file, which approves edits and
prompts on shell commands - practically the inverse of the complaint.

One judgment was stated as a judgment: an injected instruction that changes visible working
behaviour ought to be documented and individually disableable. That was drafted as product
feedback, queued locally for Torben to send or discard.

---

## Outcome

| Artifact | Result |
|---|---|
| Working method | `Edit`/`Write` for file changes; Bash for `git`, `pytest`, `wikitool`, `grep`. Persisted to the assistant's memory |
| Corrections made | The claim that a `/auto` slash command exists was wrong and was retracted |
| Documentation status | `auto` mode documented; its Bash preference not |
| Repo | No change. This turn produced no commit |