Daybreak Blue's Instructions Changed. So Did My Security Workflow.

On August 7, OpenAI introduced Daybreak Blue. I was excited.

The official docs describe it as access to frontier general-purpose models with fewer refusals for authorized defensive security work. They list vulnerability discovery, secure code review, incident response, malware analysis, and patch validation. For an independent researcher, that sounded close to the tool I had been waiting for.

Most of my work is a chain of small hunches: read the code, test an edge case, follow the state, then write down what survived. A model that can stay in that loop is a big deal.

And when Daybreak Blue worked, it was excellent.

A rough start

When I first got access, capacity was the main problem. My terminal kept reporting that a 40,000,000-token-per-minute limit was fully used.

Codex fell back from WebSockets to HTTPS. Sessions disconnected before they finished. The same limit appeared again and again. For long stretches, the model was almost impossible to use.

I was still patient. New tools wobble. I sent smaller pieces of work, resumed broken tasks, and waited out the limits. Even then, Daybreak Blue helped me find several real vulnerabilities very quickly. I cannot name the targets yet because the disclosures are still private.

That first experience matters. I wanted to understand why my workflow got worse later, not complain about a rough first day.

Then the workflow became more defensive

Later, the same model felt different.

Before doing the work, it spent more time talking about boundaries. It explained what it would not touch, inspect, or change. It sometimes asked for clarification even when the task already looked inside the scope I had given it.

Some tasks fell into a loop: check the rules, repeat the scope, ask for confirmation, then start over. I understand the safety reason. For a security agent, stopping too often is usually cheaper than crossing a real authorization boundary. But in my work, the balance had moved far enough to hurt speed and completion quality.

The model was still smart. It could read the code, find the dangerous edge, and explain the attack chain. The hard part was getting a short, usable result without the boundary discussion taking over.

Then I found a hard clue: two Daybreak root sessions started only 61.728 seconds apart. Every visible setting I could compare was the same, but the sessions loaded different base instructions.

The report was not usable

My first reaction was simple: I could not submit this report.

The finding was real. But the draft spoke to an internal review process instead of the person who would receive the disclosure. It put boundaries, unperformed actions, and risk notes in front of the finding until the useful part was buried.

The figure below is an English reconstruction of the raw Codex blind-review output. It is not the later report that I had Claude polish. I translated the visible Chinese lines and kept their order, emphasis, and redactions. The target, finding, file paths, and verdict remain hidden because the disclosure is still private.

A blind review should discuss scope. That is part of its job. The problem was balance. This example shows what I saw, but one example cannot prove why the behavior changed.

The Sol test was not a clean model test

At first, I thought one blind review gave me a clean Daybreak-versus-Sol test. It did not.

A Daybreak parent session started the reviewer with an explicit gpt-5.6-sol model override and fork_turns set to none. The child said Sol, but its session record still contained the exact 17,298-character base used by the Daybreak parent. A sibling child running GPT-5.5 received the same base.

The Codex 0.147.0 source matches this result. Codex copies the parent's base instructions into the child first. It applies the model override afterward. fork_turns: none drops the conversation history; it does not clear the base instructions.

So this run compares session policies, not fresh standalone models. Keeping one policy across child models may be intentional, especially if Codex is trying to keep authorization rules consistent.

In my own work, GPT-5.6 Sol can follow the exact wording of a rule so closely that it loses track of the wider task. That effect felt stronger under the inherited base. This is my working observation, not a general benchmark of Sol.

A clean model comparison would need fresh processes with separately initialized instruction state.

Sixty-two seconds

The useful evidence came from two user-started root sessions in my local Codex history.

They began 61.728 seconds apart on August 11. Both recorded gpt-daybreak-blue-latest, Codex 0.147.0, the same working directory, max effort, and pragmatic personality.

One session embedded 17,730 characters of base instructions. The other embedded 17,298.

This was not one damaged session. In the local history I audited, the longer variant appeared six times and the shorter one 105 times. The two versions overlapped in time. The shorter one became dominant.

What changed

The words matter more than the character count.

The older version told the agent to keep taking safe, in-scope action. It said to persist through terminal problems and make informed assumptions that keep the task moving without changing its intent.

The newer version removed those passages. It treated permission failures, approval requirements, and protected workflows as reasons to stop and ask for direction.

The logs show what changed, not why. Because Daybreak is built for defensive security work, an intentional safety correction is a reasonable explanation. Clear stop rules make it less likely that unclear authority will be treated as permission.

OpenAI's current docs show the same tradeoff. Daybreak Blue is meant to reduce refusals for authorized defensive work, while sensitive actions still need strong review and clear limits.

Think of two flight controllers. One says: stay inside the safe airspace and keep flying. The other says: if the instruments disagree, stop and call the tower.

No single default fits every workflow. The later policy may lower authorization risk. It may also create more false stops and more defensive writing during legitimate research.

This was a control problem

People often talk as if the model weights are the whole product. They are not. What the user gets is the model plus base instructions, project instructions, tools, approvals, the environment, and the result of the last action.

A great engine can still feel bad if the control software keeps hitting the brakes. The engine did not need to become weaker. A different controller was enough to change the ride.

That fits what I saw better than saying the model became dumb. Daybreak would inspect, warn, stop, ask, inspect again, and warn again. Each step made sense on its own. Together, they formed an expensive loop.

I cannot inspect the model weights. The records show something narrower: the instruction policy changed while the visible alias and CLI stayed the same. The direction of that change matches the behavior I saw.

Why one base policy affects everything

Security research needs clear boundaries. But researchers also write reports, build test sites, fix servers, and analyze data.

A base policy follows all of those tasks across a session. In Codex 0.147.0, it can also follow a child-model override inside that session.

So the policy affects more than one risky action. It shapes planning, persistence, writing style, assumptions, and what the model thinks a finished task looks like.

Strong controls still belong at real boundaries: scoped tools, permission profiles, approvals for important actions, and a clear testing scope. The base policy should support those controls without taking over ordinary analysis and report writing.

The workaround

Codex has a documented setting called model_instructions_file. It is not hidden. The official configuration reference calls it a replacement for built-in instructions.

I pointed it at a short instruction file. The file asks the agent to keep moving on safe work inside clear scope, make informed assumptions that preserve intent, avoid repeating the same boundary warning, and write reports for the person who will read them.

I tested the replacement with a matched pair on the same Daybreak path and Codex version. The default run used 14,040 input tokens. The custom run used 10,632, a difference of 3,408. The default run also recognized a literal line from the built-in opening; the custom run did not. That supports replacement rather than layering.

The workflow improved for me, but this was not a lab benchmark. It is also a broad workaround: the custom file becomes the base, so it must still describe the safety and authorization behavior the workflow needs.

What this proves, and what it does not

The evidence supports an instruction-policy change in the Daybreak sessions I observed. The session records and Codex 0.147.0 source also show that the base can survive a child-model override. That inheritance may be intentional. The Sol child tells us about the session, not about a fresh standalone Sol run.

Replacing the base improved my workflow. The diff is a plausible reason because it changed the same behaviors that got worse. But I did not run a controlled benchmark, so I cannot call it proof of cause.

This does not prove OpenAI's intent, a change to the model weights, or a change to every fresh Sol session.

I kept a sanitized evidence bundle with the matched session receipts, recurrence counts, public diff, inheritance trace, and audit script. It is linked below for anyone who wants to check the record.

What OpenAI should make clearer

First, document how base instructions move into child tasks. fork_turns: none sounds isolated, but it does not isolate the instruction layer in Codex 0.147.0.

Second, show the source and revision of the active base in session metadata, codex status, or codex doctor. Users should not need to inspect private logs to tell which policy is running.

Longer term, clear behavior profiles could help legitimate workflows choose the right balance between boundary sensitivity, normal engineering autonomy, and report writing without weakening hard permissions.

I still want Daybreak Blue

Daybreak Blue is genuinely powerful. That is why I wrote this.

Even through the connection failures and the TPM wall, it helped me move from a vague suspicion to real vulnerabilities faster than I expected. The earlier instruction policy fit my workflow better. The later one may reflect a reasonable safety tradeoff, but that tradeoff needs clearer documentation.

If the model weights are the engine, the base instructions are the flight controls. A change to either one can change the result. Users need enough version information to tell them apart.

Show the controller's source, revision, and inheritance rules. Then researchers can adapt their workflows with accurate information.