Two successful reservations do not prove concurrency: the second could start after the first ends. Earlier chapters cover target retention and scoped stopping. Here I explain the assertions that support the narrower claim that two actual executions overlapped and reached their own destinations.
Give one procedure two distinct inputs
The test creates one input/wait/extract recipe and registers its catalog ID in another project. A and B receive different values and start addresses. Reusing one definition avoids accidentally comparing two independently authored programs when the question is execution under separate contexts.
Owned HTML replaces the web response and delays its completion marker. The executor is an actual Python plugin; the test does not exercise a public service's reservation server. Controlled conditions expose definition reuse and project-specific inputs without involving customer manuscripts or login values. Keep that fixture choice beside the concurrency claim.
Observe a moment when both statuses are running
Both reservations receive the same at value. The loop reads both project lists and sets simultaneous only if both are running in one observation. Final assertions require that flag as well as two succeeded statuses. The test therefore checks more than an end-state list.
This observes overlapping execution intervals, not simultaneous physical CPU instructions. A deliberate wait helps avoid missing overlap between polls. It does not certify exact-time scheduling or supply a throughput benchmark under every load. State the operational property being observed rather than attaching a broader performance claim to the same boolean.
Compare tab ownership and run identity after completion
After completion, the run IDs must differ and each result's tabs must contain its project's original tab. A generic success label could survive a result pointing at the wrong tab, so target ownership receives a separate assertion. Distinct input values make crossed results easier to recognize too.
Each task also records zero internal model calls, evidence about the existing Python procedure path. That is not a zero-cost measurement of the external Codex conversation or entire test. Reusing a definition must preserve independent run identities and result contexts, and the test checks those identities instead of assuming them from different project names.
Retain the project the person is actually viewing
The test keeps B visible while reading and executing A's MCP context, then checks that the selected workspace is still B. A successful background job that steals the visible project would break the independent-workspace experience despite correct output data.
This connects to projectHost's cursor and interactive condition. Task selection differs from visible-window selection, so target movement need not move the person's focus. The test adds visible-state preservation to result assertions. Its actual tabs and kernels live in a separate owned profile rather than repurposing the person's operational workspace for the experiment.
Retain the environment and measurement boundary
Source and packaged records each contain fifteen checks including overlap and target retention. Their total elapsed field includes preparation, copying and UI checks; it is not the duration of just two reservations. A number needs the measured interval as well as a unit.
This article compares code and saved results without creating new reservations. The feature remains a local scheduler operating while the app is on, with no execution during shutdown or sleep. The reusable test design replaces a vague concurrency claim with separate assertions for overlap, ownership and visible-state retention. Each condition can fail independently and therefore deserves its own evidence.