Codex Desktop automation_update can false-succeed without owner-host persistence or readback

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.707.72221 (build 5307), signed macOS app bundle
com.openai.codex. Bundled/session CLI: codex-cli 0.144.1.

What subscription do you have?

ChatGPT-signed-in desktop session. The exact paid tier is not exposed to this
task.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

automation_update has no durable owner-host identity or authoritative
owner-readback contract. In a Remote Control / controller-host workflow, an
update can be accepted by the controller-side Desktop path while the automation
owned by the connected host remains unchanged. The caller can therefore receive
a success-shaped result without proof that the requested owner state was
persisted.

Current safe recheck on build 26.707.72221:

• view accepts only id and returns a rendered card, not a structured owner

locator, revision, or persisted state receipt.

• update/delete expose an automation id plus target fields, but no opaque

owner-host locator, expected revision/CAS, or idempotency key.

• The public openai/codex main branch exposes dynamic-tool discovery/dispatch,

but no merged automation-management RPC or owner-store implementation.

The concrete false-success was reproduced on an earlier Desktop build in the
same architecture line: the update path returned success-shaped data while the
owner-host prompt/RRULE stayed old. The current build was not mutated again
because its schema still cannot identify the owner or prove the commit. A
sanitized durable report is available in
https://github.com/GoloCatMash/viko/issues/1266.

What steps can reproduce the bug?

Use disposable no-op test automations only; do not edit a production automation.

1. On owner host B, create a disposable automation with a unique prompt marker

and a next run safely beyond the test window.

1. Connect from controller host A through Remote Control and open a thread whose

tools/project come from host B.

1. Call official automation view for the disposable automation. Observe that

the result contains no opaque owner locator or revision.

1. Call official update with all non-target fields preserved and change only

the prompt marker or RRULE.

1. Immediately compare the tool result with official owner-host view and

read-only owner persistence/scheduler state. Also verify that controller host
A did not create or mutate an automation with the same ID.

1. Repeat the owner reads after at least 45 seconds.

The failure is any success response when owner state does not exactly match the
requested target, any controller-store mutation, or any inability to identify
which host owns the returned state.

What is the expected behavior?

1. view returns an opaque owner locator containing enough identity to bind the

host and automation, plus a revision and machine-readable persisted state.

1. update and delete require that locator, expectedRevision, and an

idempotency key. Unknown, unreachable, wrong, or ambiguous hosts fail before
a write; there is no local projectId fallback.

1. The owner serializes by (ownerHost, automationId), applies CAS, and keeps an

idempotency record across disconnect/retry/restart. Same key + same payload
returns the same receipt; same key + different payload fails.

1. Success is returned only after the owner reads the committed automation and

scheduler state back and verifies every requested field plus unchanged
non-target fields. An in-memory desired object is not a success receipt.

1. Partial TOML/state-DB/scheduler persistence and uncertain disconnect outcomes

return typed errors such as unknown_host, ambiguous_host,
stale_revision, connection_lost, partial_persistence, or
commit_outcome_unknown.

1. Tests cover local owner, Remote Control, concurrent writers, stale revision,

idempotent retry, disconnect before/after commit, restart, each partial-write
boundary, the historical false-success case, and immediate plus >=45-second
owner readback of RRULE, prompt SHA-256, revision/updatedAt, next run, and all
non-target fields.

Additional information

Related but distinct issues:

• #32294: tool exposed without a handler.
• #32873: cwds versus projectId schema mismatch.
• #29128: inconsistent tool exposure across local threads.
• #26489: Remote Control does not expose the automation tool.
• #32609: manifest/scheduler behavior.
• #25873: visible tool rejected as non-local.

None covers the success-without-owner-persistence/readback contract above.

There is also a closed official draft stack #28609–#28620 that added a durable
Rust automation store, CRUD/scheduling, claims/leases, app-server protocol and
handlers, an agent automation_update tool, and integration coverage. Those PRs
were closed after inactivity. Maintainer guidance is requested: should that
stack be revived and extended with owner locator/CAS/idempotency/readback, or
should this be fixed in the private Desktop owner/store path?

No direct TOML, SQLite, UI, ASAR, memory, or scheduler fallback write was used.