Unattended Codex tasks

Scheduled personal Codex tasks are a proposal, not a delivered feature. The 2026-09-22 investigation on memex.systemorph.com prepared a personal bug-fix task with harness Codex, agent bug-triage, and model gpt-5.6-terra, but established no schedule. Connecting Codex and submitting a message do not enable unattended recurrence. The account-startup repair and this scheduling proposal are separate work.

What exists today

An authenticated caller can resume an existing task through submit_message or Mesh.SubmitMessage. The durable Thread.PendingUserMessages inbox and its owning hub dispatch the round. The Codex harness then resumes the task's Codex session using the effective user's credential and configuration directory; see the app-server protocol.

EventSubscription provides persistent Timer triggers with RepeatEvery, but its RunScript continuation executes as system-security, not as the subscription creator. The kernel preserves that delivery identity. System access to a person's private task or GitHub credential therefore relies on infrastructure privileges that bypass row-level checks. The subscription's CreatedBy field is audit metadata, not authorization to execute as that person. Do not use this path as a substitute for delegated personal execution.

The thread's persisted-owner fallback does not close that gap: it reconstructs identity for a round after submission has been authorized. It does not authorize a scheduler's preceding reads of private content or its input write. Authoritative persisted ownership must be verified before enabling any owner-bound schedule; an incomplete projection is not proof of ownership.

Other existing mechanisms do not supply the missing behavior:

AgentTask is shared context for ordinary participant threads, with no independent schedule.
ThreadSupervisor recovers pending or stalled rounds. An idle task with no pending input does not cause it to inspect a backlog or submit more work.
Hosting triage intake starts event-specific tasks with its own system-owned triage agent; it is not a personal Codex/Terra queue configuration.
PostThreadMessage exists in the continuation enum, but no handler was found in the inspected core or Plugins implementation. ReminderSchedule supplies timing helpers, not a thread runner. Governance scheduling descriptions are proposed work, not a supported setup path.

Proposed native feature

The smallest supported extension should reuse the existing timer and thread inbox, with two new contracts. This changes authorization and durable execution semantics; it needs review and tests, not an executable script placed on a production mesh.

Owner-authorized scheduling. Enabling a schedule must be an authenticated action on the existing task. The owning hub captures the caller's identity, verifies the caller is the task's persisted owner and has the required current permission, and persists that bounded authorization. The caller cannot nominate a different run-as user. Each wake revalidates the authorization and current access before running private reads or submission under the owner's scoped identity. Disabling the schedule, revoked access, a missing owner, or missing credentials must fail closed; there is no system fallback. Ownership alone and global-admin status are not access grants.

Conditional, idempotent canonical submission. The owning Thread hub must check the expected previous response and current active, pending, control, and terminal state, then record the occurrence key and append its input in one durable conditional update. The operation must return an observable acknowledgement distinguishing submitted, duplicate, busy, blocked, and denied outcomes. A duplicate occurrence must not append again. A crash after commit resumes the existing inbox item; a crash before commit permits retry. These are proposed semantics, not existing API or schema names.

Today's SubmitMessage returns void, while ThreadInput.AppendUserInput generates a fresh ID for every call. Neither accepts an occurrence key or acknowledges durable success. A separate create-only claim followed by submission leaves a crash gap between the two writes. Checking an idle task in a script also cannot atomically prevent a user submission from racing it. Extend the canonical owner-side submission path instead of editing thread state from a script.

For the initial worker, bind one existing task to Codex and gpt-5.6-terra, with an explicit allow-list of Systemorph/MeshWeaver and Systemorph/MeshWeaver.Plugins. A proposed ten-minute interval and three-minute backlog-check budget bound idle polling. Read current open issues through the existing GitHub service, excluding pull requests; an empty backlog causes no model round. Select one actionable bug per round, re-read its live issue, check for existing work, and record new defects only after checking for duplicates.

Skip active rounds, pending input, composer drafts, and control requests. Resume only after a successful round explicitly allows continuation. Authentication-required, awaiting-input or approval, cancelled, terminal, and failed outcomes stay stopped until the owner resumes them. Never automate account login or silently fall back to another harness. Resolve credentials at runtime; store none in schedule content, prompts, or logs.

Reusable primitives and source evidence

The investigation inspected core revision da9a3ecc9e and the corresponding Plugins sources on 2026-09-22. The relevant boundaries are:

Source	Existing behavior or reusable primitive
Core `MeshWeaver.Graph/EventSubscriptionRunner.cs`, `ExecuteContinuation`	Timer dispatch, recurring rearm, and `RunScript` under `AsSystem`. `IEventContinuationHandler` is the extension point for AI-owned effects. Timer delivery is at least once.
Core `MeshWeaver.Graph/Configuration/CodeNodeType.cs`, script dispatch	Each invocation creates a fresh Activity and kernel; scripts on one Code node are not mutually exclusive. `ExecuteScriptResponse` acknowledges dispatch, not completion.
Core `MeshWeaver.Kernel.Hub/KernelExecutor.cs`, execution leaf	Carries the submission's explicit identity into the script.
Core `QueryIdentity`, `RlsNodeValidator`, `PartitionWriteGuardValidator`	System reads bypass RLS and system writes bypass ordinary user checks. This is infrastructure privilege, not a delegated owner grant.
Core `ImpersonationScopeExtensions.RunAs` and `HubPermissionExtensions.CheckPermissionOutcome`	Carry an already-authorized identity through a cold observable and check an explicit user's permission. Neither establishes consent to schedule as another person.
Plugins `MeshWeaver.AI/ThreadInput.cs`, `HubThreadExtensions.cs`	Canonical user-input construction and append. The existing pure `ApplyUserInput` and durable inbox can support the proposed conditional operation.
Plugins `ThreadSubmission.cs`, `ThreadExecution.cs`; core `AccessContextScope.cs`	Submitter capture and persisted-owner reconstruction. Owner execution inherits the authorization established at submission.
Plugins `CodexHarness.cs`; core `GitHubCredentialService` and `IGitHubRepoClient.ListIssues`	Existing per-user Codex and GitHub credentials, plus current issue reads. Use under the authorized owner; no new token store is needed.

Required verification

Before shipping, execute tests covering owner-only enablement, cross-user refusal, revoked access, missing ownership, duplicate deliveries from two replicas, and crashes before and after durable submission. Exercise busy, draft, pending, terminal, authentication, and user-intervention guards; empty backlog and GitHub errors must not start model rounds. Verify repository, harness, and model binding and that no credential values enter persisted content or logs. Finally, verify one real owner-authenticated wake and a duplicate delivery without an extra round on the target mesh.

No schedule, Code node, access grant, or worker loop was created during this investigation. The exploratory local script was not compiled or deployed and cannot run through the current system timer. This document preserves the finding for the future native feature.