Skip to content

[web] Fail closed until Core execution compatibility is publicly proven #24

Description

@sam2tom

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 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.
  • Existing Sessions, Items, Turns, Usage, Environment state, metadata, deletion, recovery, SSE, and cancellation remain usable.
  • 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.

Activity

  1. sam2tom commented on Sep 16, 2026

    @sam2tom
    CollaboratorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions