CLI 0.154.0: Astra safety block during local bug fixing followed by a new conversation

What version of Codex CLI is running?

codex-cli 0.154.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-6-astra; reasoning effort high; provider openai

What platform is your computer?

macOS 15.4.1 (24E263); Darwin 24.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

JetBrains-JediTerm (integrated terminal); version not verified

Codex doctor report

codex doctor --json was run locally after the incident. Overall status: warning.

Installation, authentication configuration, HTTP provider reachability and the Responses WebSocket handshake passed. Warnings: desktop security assessment unavailable; optional MCP configuration issues; rollout/state-DB inventory mismatch (51 missing active rows and 35 scan errors). These warnings have not been established as causes of the safety block or conversation transition.

A separately prepared doctor.redacted.json retains the diagnostic report with personal paths, unrelated configuration details and unrelated thread samples removed. The report reflects the environment after the incident, not the exact process state at the block.

What issue are you seeing?

During an authorized code-maintenance task in my own real-time audio/video application, Codex displayed:

ⓘ This content can’t be shown
  Daybreak isn’t available for Astra. Some cybersecurity requests may still be limited.
  Learn more: https://help.openai.com/en/articles/20001326

• You’re continuing from this point in a new conversation

The task was to audit and correct the application and its dependencies, run local regression/sanitizer tests, and collect detailed latency diagnostics for later analysis. Latency optimization was explicitly excluded. The recent work involved SCTP receive-state synchronization and teardown tests with two endpoints exchanging data inside one local process.

This appears to be a safety-check false positive in a maintenance workflow. I cannot identify the exact triggering model request or establish whether the conversation transition was caused by the block. Please inspect the uploaded trace rather than treating the maintenance description as a minimal reproducer.

The interruption disrupts a long-running goal and leaves uncertainty about which conversation owns the goal and whether it will continue automatically.

What steps can reproduce the bug?

Uploaded thread: 01a09b0c-157e-7052-a0c0-8c6984a1dbea

1. Use Codex CLI with gpt-6-astra and high reasoning on an owned application repository.
2. Pursue a persistent goal covering code audit, defect remediation, regression tests and diagnostic data collection.
3. Continue local dependency concurrency/teardown debugging and sanitizer validation.
4. Observe the safety notice and subsequent new-conversation notice above. Use Codex feedback to upload the thread.

This is the observed workflow, not a deterministic minimal reproducer. The uploaded thread metadata records forked_from_id = 01a09a8e-887a-7f83-bba4-27151c82476b. Please inspect the parent as well as the uploaded continuation when locating the blocked request.

The continuation was created at 2026-09-13 13:54:15.586 UTC (14:54:15.586 BST, Europe/London). This is the verified continuation timestamp, not a verified timestamp for the safety block. The uploaded continuation's latest recorded model is gpt-6-astra, effort high, provider openai, CLI 0.154.0.

What is the expected behavior?

Authorized maintenance should proceed when permitted. If a safety check blocks a turn, show a clear recoverable status and the supported next step. Preserve the task checkpoint and active goal, or explicitly explain how they transfer to a continuation. Make the parent/continuation relationship clear and include enough diagnostic identifiers for support to find the event. I am requesting false-positive review and reliable recovery, not removal of safeguards.

Additional information

A previous attempt in this workflow also displayed Failed to update thread goal: thread/goal/set failed in TUI. I do not know whether that is related; the parent goal was later verified active.

Related reports with similar Astra safety notices: https://github.com/openai/codex/issues/44805 and https://github.com/openai/codex/issues/43131. This report adds the feedback-uploaded thread and the new-conversation/goal-continuity symptom; please link or consolidate if appropriate.

The safety-message help article requests exact messages, model, timing and a redacted task description: https://help.openai.com/en/articles/20001326. The uploaded thread was supplied through the Codex feedback workflow. No private source, credentials or raw session logs are included in this public draft.

Terminal version has not been verified.

No source file or test is named. Start by inspecting the uploaded continuation thread 01a09b0c-157e-7052-a0c0-8c6984a1dbea and its parent 01a09a8e-887a-7f83-bba4-27151c82476b, focusing on the safety notice, conversation transition, and goal-update failure. Done should establish the triggering event and define or verify recoverable checkpoint and continuation behavior.