You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[web] Fail closed until Core execution compatibility is publicly proven #24
Agents Core Web currently enables Turn-driving writes after an idle Session is loaded and its SSE stream is listening. Those signals prove API and stream availability, not native executor compatibility.
A real local audit against Parsar d91ba48 found that the public API exposes no versioned execution-readiness or capability resource. The private daemon advertises engine capabilities, but its current Codex environment_none signal is based on binary presence and can still fail during native preparation. The shipped sandbox defaults to Codex 0.141.0, while the pinned native Environment reference is 0.153.4; the first Turn can therefore be admitted and then fail before model execution when environment/status is unavailable.
This is the Web implementation follow-up to capability tracker #8. It does not authorize or require a Parsar change.
Bounded outcome
Add one centralized execution-compatibility state with supported, unsupported, and unknown semantics; default to unknown.
Permit message, steering, and function-result writes only when compatibility is explicitly supported by a future versioned Core contract.
While compatibility is unknown or unsupported:
keep Agents and idle Sessions manageable;
keep Session, Item, Turn, Usage, Environment, and SSE observation read-only;
keep cancellation available for already-active work;
disable the composer and function-result submission with a visible, keyboard-accessible explanation;
enforce the same block in the final App write boundary, not UI controls alone.
Do not infer support from health, Agent CRUD, idle Session creation, SSE state, model ID, Environment connection, static revision, or a prior failed/successful Turn.
Document the exact contract needed to move compatibility to supported.
Acceptance criteria
With the current Core surface, no user action can POST a new message, steering input, or function result.
Directly bypassing disabled controls still reaches an App-level guard and produces no execution write.
The unavailable explanation says that execution compatibility is not publicly proven; it does not claim the Core, daemon, model, provider, or credentials are absent.
Unknown and malformed capability data fail closed.
Fixtures and tests prove the negative write boundary at desktop and narrow widths.
docs/protocol-coverage.md, pnpm check, Playwright acceptance, and git diff --check pass.
Future unblock contract
Selective enablement requires a public, versioned, tenant/session-scoped execution profile whose readiness is derived from native method probing for the exact engine and Environment mode. A Core revision string or private heartbeat alone is insufficient.
Non-goals
No Parsar Core, daemon, Codex, provider, launcher, deployment, database, or container changes.
No version sniffing, hard-coded revision allowlist, health/SSE inference, or browser-emulated readiness.
No model request, paid validation, automatic retry, release, deployment, merge, or branch/Worktree deletion.
Closing as superseded by the validated contract direction merged through #25 and #23.
The original proposal treated the absence of a separate public execution-readiness resource as a reason to block all new message, steering, and function-result writes. Live validation against Parsar d91ba48 established that the versioned agents=v1 Session-events endpoint is the current public chat contract, and the complete local Web -> Core -> daemon -> Codex -> provider -> assistant path succeeded.
The merged Web now:
uses that documented events contract and requires exact HTTP 204 admission;
never retries an uncertain write automatically and reuses a key only for an explicit unchanged manual resend;
leaves runtime/model/provider failures visible in durable Core state rather than calling them readiness;
hides top-level Environment management that Core does not expose.
Therefore the negative-write acceptance criteria in this Issue were intentionally not implemented. A future versioned readiness/profile resource, if still desired, should be tracked as a separate additive capability rather than blocking the working contract. No Parsar source was changed and nothing was deployed.
Context
Agents Core Web currently enables Turn-driving writes after an idle Session is loaded and its SSE stream is listening. Those signals prove API and stream availability, not native executor compatibility.
A real local audit against Parsar
d91ba48found that the public API exposes no versioned execution-readiness or capability resource. The private daemon advertises engine capabilities, but its current Codexenvironment_nonesignal is based on binary presence and can still fail during native preparation. The shipped sandbox defaults to Codex0.141.0, while the pinned native Environment reference is0.153.4; the first Turn can therefore be admitted and then fail before model execution whenenvironment/statusis unavailable.This is the Web implementation follow-up to capability tracker #8. It does not authorize or require a Parsar change.
Bounded outcome
supported,unsupported, andunknownsemantics; default tounknown.supportedby a future versioned Core contract.unknownorunsupported:supported.Acceptance criteria
docs/protocol-coverage.md,pnpm check, Playwright acceptance, andgit diff --checkpass.Future unblock contract
Selective enablement requires a public, versioned, tenant/session-scoped execution profile whose readiness is derived from native method probing for the exact engine and Environment mode. A Core revision string or private heartbeat alone is insufficient.
Non-goals