New sessions were stopping at a dialog
there is a general issue with spinning up new sessions: they often ask stupid things like "do you want to update now" or "do you trust this folder"
Real spawns through the manager, with copied credentials and brand-new workspace folders.
The task given at launch was reply with exactly READY, and nothing was typed by hand.
Before — the task never runs
Both panes sit at a trust dialog. READY appears 0 times in either transcript: the work was dispatched and did not start.
> You are in /home/node/local/fr-state3/workspaces/pre-codex Do you trust the contents of this directory? Working with untrusted contents comes with higher risk of prompt injection. Trusting the directory allows project-local config, hooks, and exec policies to load. › 1. Yes, continue 2. No, quit Press enter to continue
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Accessing workspace: /home/node/local/fr-state3/workspaces/pre-claude Quick safety check: Is this a project you created or one you trust? (Like your own code, a well-known open source project, or work from your team). If not, take a moment to review what's in this folder first. Claude Code'll be able to read, edit, and execute files here. Security guide ❯ 1. Yes, I trust this folder 2. No, exit Enter to confirm · Esc to cancel
After — straight to work
Same spawn, same folders, nothing typed. Both answer READY.
╭──────────────────────────────────────────────────────╮ │ >_ OpenAI Codex (v0.149.0) │ │ │ │ model: gpt-5.6-sol xhigh /model to change │ │ directory: /home/node/local/…/workspaces/fix-codex │ │ permissions: YOLO mode │ ╰──────────────────────────────────────────────────────╯ Tip: You can run any shell command from Codex using ! (e.g. !ls) › reply with exactly READY • READY › Ask Codex to do anything gpt-5.6-sol xhigh fast · /home/node/local/fr-state2/workspaces/fix-codex
╭─── Claude Code v2.1.232 ─────────────────────────────────────────────────────────────────────────────────────────────╮ │ │ Tips for getting started │ │ Welcome back Leandro! │ Ask Claude to create a new app or clone a repository │ │ │ ─────────────────────────────────────────────────────────────── │ │ ▐▛███▜▌ │ What's new │ │ ▝▜█████▛▘ │ Added a `keybindingFlavor` setting: set it to `"readline"` to … │ │ ▘▘ ▝▝ │ Plugin marketplaces: `headersHelper` on a url marketplace or a… │ │ │ A catalog entry's `headersHelper` runs only when you install o… │ │ Opus 5 (1M context) · Claude Team · Hugging Face │ /release-notes for more │ │ /home/node/local/fr-state2/workspaces/fix-claude │ │ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ❯ reply with exactly READY ● READY ✻ Worked for 1s ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ❯ ─────────────────────────────────────────────────�────────────────────────────────────────────────────────────────────── ⚠ Transcript saving is off — inherited CLAUDE_CODE_CHILD_SESSION marker · restart with CLAUDE_CODE_FORCE_SESSION_PERS… Opus 5 (1M context) · 5h 44% · wk 19% ⏵⏵ bypass permissions on (shift+tab to cycle)
What a new session actually asks
Found by launching each CLI clean, not from documentation. Trust is keyed on the absolute path, so a trusted parent does nothing for a new child — which is why this is a per-session problem.
| CLI | dialog | keyed on | recorded in |
|---|---|---|---|
| both | do you trust this folder? | absolute path | hasTrustDialogAccepted / trust_level |
| claude | managed settings / telemetry approval | settings hash | remote-settings-consent.json |
| claude | bypass-permissions warning | global | skipDangerousModePermissionPrompt |
No update dialog appeared for either CLI, so nothing here touches update checking. The bypass warning's default button is No, exit — a blind Enter on it quits the session, which is why answering it blindly is not a workaround.
What happens to the launch prompt behind a dialog
This decides whether pre-answering is enough, so it was measured rather than assumed.
| the launch argument | survives — queued, and runs once the dialog is answered, on both CLIs |
|---|---|
| a prompt sent while the dialog is up | partly eaten — reply with exactly SECOND arrived as with exactly SECOND; its Enter dismissed the dialog, which released the queued first prompt |
| waiting for readiness first | does not help — the manager waits for a quiet screen, and a dialog is a quiet screen |
Which explains the report exactly: the task "only started after I sent the prompt a second time" — the second send was answering the dialog.