Field test status: diagnostic pass completed; upstream direction pending.
This one is different from the merged patch reports.
The Electron case produced a narrow draft repair and a focused regression test, but it did not land as-is. Maintainer review raised a security-boundary concern, and the repair lane was paused pending clarification of Electron’s intended behavior.
That makes it a useful field test anyway.
Sometimes a diagnostic field test proves the patch.
Sometimes it proves the boundary question.
This one did the second thing.
Target
Repository: electron/electron
Issue: #48240
Draft PR: #51991
Issue title: [24.1.0 regression] Unsandboxed preload is restricted by Content-Security-Policy, but only after readyState becomes interactive
Public PR title: fix: don't apply page csp to isolated preload codegen
The reported failure
The issue reported inconsistent behavior in Electron preload execution.
In an unsandboxed preload script with contextIsolation: true, string code generation such as new Function(...) could be allowed early in preload execution, but later become blocked after the document moved into the interactive phase.
That matters because some libraries detect code-generation support once, cache the answer, and then rely on that answer later.
So the failure was not simply “CSP blocks eval.”
The failure was temporal inconsistency.
The same preload context appeared to answer the code-generation question one way at the beginning of execution and another way after document parsing progressed.
That is a drift-shaped failure.
A truth changed mid-context.
Why this is a boundary problem
Electron sits between several worlds at once:
Chromium page behavior.
Electron preload behavior.
Node-enabled application behavior.
Content Security Policy.
Context isolation.
Application security expectations.
That makes the boundary important.
The diagnostic question was not only:
“Should code generation be allowed?”
The better question was:
“Which policy owns code generation inside an isolated preload world, and should that answer change after document parsing begins?”
That is the boundary.
The page has a Content-Security-Policy.
The preload script runs in an Electron-managed isolated world.
The app may rely on preload behavior.
The security model may rely on the page CSP applying transitively.
If those ownership lines are unclear, the runtime can become inconsistent.
That is exactly what the issue exposed.
The first repair lane
The draft repair tested one interpretation of the boundary:
If the preload script runs in Electron’s isolated world, then page CSP should not make preload string code generation change after document parsing begins.
The patch added a check for Electron’s isolated world and routed that case around the page CSP code-generation callback, while keeping page CSP enforcement for main-world renderer code.
It also added a regression test for an unsandboxed, context-isolated preload under a restrictive page CSP. The test verified that string code generation stayed consistently allowed both before and after DOMContentLoaded.
That was a narrow patch.
Two files changed:
shell/common/node_bindings.cc
spec/chromium-spec.ts
The focused regression test passed locally.
Maintainer review changed the repair lane
Electron maintainer review raised the key concern:
If apps are already relying on the page CSP as a transitive guard against eval-like behavior in isolated preload code, then bypassing page CSP for isolated preload code generation may weaken the security posture.
That is the important moment in this field test.
The diagnostic pass found a real inconsistency.
The first repair lane made the behavior consistent in one direction.
Maintainer review clarified that consistency in that direction may not match the intended security boundary.
So the responsible next step is not to force the patch.
The responsible next step is to pause and ask which boundary Electron intends:
Should page CSP block preload eval-like code generation consistently from the beginning?
Or should Electron eventually expose a separate, explicit isolated-world code-generation control?
That is now the design question.
Why this still belongs in Field Lab
A field test does not have to end with a merged PR to be valuable.
The diagnostic value here is that the failure was reduced from a confusing runtime regression to a precise boundary question:
Should an isolated preload world inherit page CSP code-generation limits?
If yes, the current behavior is inconsistent because enforcement appears only after document parsing progresses.
If no, the current behavior is inconsistent because page CSP eventually reaches into a world it should not govern.
Either way, the bug is not random.
It lives at the ownership boundary between page security policy and Electron preload execution.
That is the Scarab-relevant finding.
What this case shows
This case shows why software drift diagnostics cannot stop at “make the failing behavior consistent.”
Consistency is not automatically correctness.
A repair can make a system internally consistent while still moving the wrong security boundary.
That is especially true in runtime platforms like Electron, where a boundary may be both functional and security-sensitive.
The first patch made one interpretation explicit.
Maintainer review surfaced another possible truth: some applications may depend on the current transitive CSP behavior as a security guard.
That changed the repair question.
Not because the failure disappeared.
Because the authority question became clearer.
The Scarab reading
The issue was not merely a code-generation bug.
It was a policy-carrier bug.
The code-generation answer changed as the document lifecycle advanced.
The same preload context did not receive a stable answer across execution phases.
The draft repair proved that the behavior could be made consistent.
Maintainer review proved that the direction of consistency matters.
That is the lesson.
In drift work, the goal is not just to remove a diff or quiet a failing case.
The goal is to identify which claim owns the behavior and what evidence authorizes that claim to move.
In this Electron case, the claim is still under maintainer/design review:
Does page CSP own isolated preload code generation?
Or does isolated preload code generation need its own explicit control surface?
Until that is answered, the safest public field-test result is not “patch accepted.”
It is:
Boundary isolated. Repair lane paused. Upstream direction pending.
Field result
Result: Significant diagnostic field test.
Patch status: Draft PR opened; not landed as-is.
Maintainer feedback: Security-boundary concern raised.
Current posture: Awaiting upstream direction on intended CSP / isolated-preload ownership.
Diagnostic finding: Electron issue #48240 exposes a lifecycle-dependent policy boundary failure between page CSP enforcement and isolated preload code generation.
Repair lane: Pending explicit decision on whether page CSP should consistently govern isolated preload code generation, or whether Electron needs a separate isolated-world control surface.
Why this matters beyond Electron
Electron is a boundary-dense platform.
It combines browser security models, desktop application power, Node integration, preload scripts, renderer isolation, and application-defined trust decisions.
That is exactly the kind of environment where software drift becomes subtle.
A behavior can be technically consistent with one layer and wrong for another.
A patch can fix a regression and weaken a security assumption.
A test can prove behavior without proving policy authority.
This is why field diagnostics matter.
The hard part is not always writing the patch.
Sometimes the hard part is finding the exact question the patch must answer before it deserves to land.
Repo truth and governance
This field test also points at the broader theory behind Scarab.
Every repository has truth.
That does not mean every repository has perfect documentation, perfect tests, or perfect architecture. It means the codebase contains obligations that must remain true for the system to keep working as itself.
Those truths are not floating abstractions.
They appear in the repo’s components.
They appear in the way those components interact.
They appear in boundaries, contracts, responsibilities, generated artifacts, runtime assumptions, configuration rules, security models, and tests.
A repo’s truth is not found in one file.
It is distributed across the agreements the system depends on.
That is why a boundary failure matters. When a boundary stops carrying the truth it was responsible for preserving, the repo can still look healthy. It can still build. It can still pass a focused test. It can even become more internally consistent.
But it may be preserving the wrong claim.
That is where governance enters.
Not governance as an ethics slogan.
Not governance as a policy document sitting somewhere outside the work.
Repo-truth governance is the mechanical process of keeping the codebase’s own truths from being silently rewritten.
It is the checks and balances that ask:
Which claim owns this behavior?
Which surface has authority here?
Which boundary is responsible for carrying that claim forward?
Did the change preserve that truth, move it, weaken it, or bypass it?
What evidence proves the movement was legitimate?
This is a different lens for AI-assisted development.
Right now, AI coding agents are often dropped into repositories with access to files, tests, and instructions, but without a governed relationship to repo truth.
They can change code.
They can change tests.
They can change config.
They can change documentation.
They can make the project appear coherent around the thing they just changed.
But unless something mechanical is governing the repo’s truth, the agent is not really being guided by the system’s obligations. It is navigating a field of states, files, and feedback loops.
That is not enough.
Governance is the bridge between repo truth and AI function.
If the repo has truth, and an AI agent is allowed to operate inside that repo, then the agent needs more than context.
It needs boundaries.
It needs authority rules.
It needs evidence gates.
It needs checks and balances that prevent it from turning a local patch into a global lie.
This Electron field test is a small but sharp example.
The first repair lane made the behavior consistent.
The maintainer review asked whether that consistency would preserve the correct security boundary.
That is repo-truth governance in action.
The patch did not simply ask, “Can this be changed?”
The real question became:
“Does this change preserve the truth Electron is responsible for maintaining?”
That is the level of the problem Scarab is built to diagnose.
Closing note
This field test is important because it demonstrates a different kind of Scarab outcome.
Not every successful diagnostic pass ends in an immediate merge.
Sometimes the value is that a confusing bug becomes a precise governance question.
For Electron, the question is now much cleaner:
What owns code-generation authority inside an isolated preload world?
That is the field finding.
And more broadly:
What owns truth inside a repository, and what governs whether that truth is preserved?
That is the industry question.
Disclosure: This field report was written with AI-assisted editing and summarization. The underlying diagnostic run, repair branch, PR status, validation commands, and technical claims come from my own Scarab/SDS field-test work and were reviewed by me before posting
