Add first-class automations for scheduled Codex workflows

[comfuture]

Summary

Codori should support first-class automations: scheduled workflows that run on a cron pattern, fixed interval, or RRULE-like schedule against a selected workspace/chat context.

This should let a machine running Codori server execute recurring Codex-powered work without requiring the user to manually start each run.

This is a large feature area covering:

• automation creation
• schedule management
• execution via Codori's own app-server/RPC path
• run history
• result inspection
• management UI

Problem

Codori is already useful as a remote control plane for interactive Codex sessions, but many developer workflows are repetitive:

• scheduled codebase checks
• recurring status summaries
• periodic dependency or CI investigations
• regular repository maintenance prompts
• recurring project reports

Today these have to be triggered manually. A server that is already running on the user's machine should be able to run these workflows on a schedule.

Important implementation direction

Use the Codori project/workflow implementation as a source of code references and product insight where useful, but do not implement this by depending on use-workflows.

This feature should be implemented as Codori's own automation system that communicates with Codex through its own managed app-server/runtime path.

In other words:

• Codori server owns scheduling and persistence
• Codori server starts/reuses the relevant app-server runtime
• Codori server talks to app-server using the same protocol concepts used by interactive chat
• the client manages automations through Codori APIs

Current code context

Relevant current code and observations:

• packages/server/src/process-manager.ts
  • owns project/chat runtime startup and app-server lifecycle concerns
• packages/server/src/http-server.ts
  • already exposes project/chat APIs and proxies app-server RPC/WebSocket traffic
• packages/client/app/components/ChatWorkspace.vue
  • shows how interactive sessions start/resume threads and send turn/start
• packages/client/app/components/message-item/DynamicToolCall.vue
  • already recognizes internal workflow-like dynamic tool names such as manageWorkflow, but this is presentation-only and not a scheduling system
• generated app-server protocol types include useful methods such as:
  • thread/start
  • thread/resume
  • turn/start
  • turn/steer
  • turn/interrupt
  • command/exec

These paths provide useful implementation references for how scheduled runs can communicate with app-server without adding a separate workflow engine dependency.

Desired behavior

Users should be able to:

1. Create an automation.
2. Choose a schedule.
3. Choose the workspace/project or projectless context where it runs.
4. Define the prompt/workflow to execute.
5. Enable, pause, edit, or delete the automation.
6. View execution history.
7. Open a run result and inspect what happened.

Scheduling requirements

The automation scheduler should support at least:

• cron patterns
• fixed time intervals
• RRULE-style recurrence rules

Implementation should define which schedules are supported in the first version and validate unsupported shapes clearly.

Execution model

A scheduled automation run should:

• resolve the target workspace/project/chat context
• ensure the needed app-server runtime is available
• start or resume an appropriate thread/session
• send the configured workflow prompt/input
• capture status, output, errors, timestamps, and metadata
• make the run result inspectable from the UI

The execution path should be robust to server restarts as much as practical.

Persistence model

Codori server needs persistent automation state, including at minimum:

• automation id
• name/title
• enabled/paused status
• schedule definition
• target workspace/project/chat context
• workflow prompt/configuration
• created/updated timestamps
• last run / next run metadata

Run history should include at minimum:

• run id
• automation id
• scheduled time
• actual start/end timestamps
• status
• linked thread/session id when available
• result summary
• error details when failed

UI scope

The client should provide interfaces to:

• list automations
• create a new automation
• edit an automation
• pause/resume an automation
• delete an automation
• view run history
• inspect a run result

This can be split into multiple implementation issues later, but the feature should be designed as one coherent system.

Management UX notes

A practical first UI could include:

• an Automations section/page
• a create/edit modal or drawer
• schedule selector fields
• target workspace selector
• prompt editor
• run history table/list
• run detail panel with linked chat/thread output

Safety and operational concerns

Because automations can run unattended on the user's machine, implementation should handle:

• clear enable/disable state
• no accidental duplicate runs after restart
• visible failure states
• time zone handling
• schedule validation
• protection against overlapping runs unless explicitly allowed
• logging enough context to debug failures

Scope

This issue should cover the overall automation feature design and first implementation plan, including:

• server-side scheduler
• server-side persistence
• app-server execution adapter
• client management UI
• run history/result UI
• tests for scheduling, persistence, execution, and UI flows

Out of scope for the first version

Potentially defer these unless they fall out naturally:

• complex branching workflow graphs
• multi-step visual workflow builder
• distributed scheduling across multiple Codori servers
• external hosted runner infrastructure

Acceptance criteria

• Users can create a scheduled automation from the Codori UI.
• Automations support at least one cron-like schedule and one interval/RRULE-like schedule shape, or the first supported subset is clearly defined and validated.
• Codori server persists automation definitions.
• Codori server runs automations through its own app-server communication path rather than use-workflows.
• Users can pause/resume and delete automations.
• Users can view execution history.
• Users can inspect run results and errors.
• Automation runs are associated with the relevant workspace/project/chat context.
• Tests cover scheduler behavior, persistence, and at least one successful app-server-backed run path.

Why this matters

Codori runs on the user's own machine and already controls Codex app-server runtimes. That makes it a natural place to run recurring developer workflows. First-class automations turn Codori from an interactive remote coding surface into a reliable personal automation layer for repeated Codex-powered work.