Additional
Task Automations
Synced from github.com/CoWork-OS/CoWork-OS/docs
Task automations turn an existing task into scheduled or triggered follow-up work without leaving the task view. By default, they continue the same conversation thread so future runs keep the context that was already built up.
<p align="center"> <img src="../resources/branding/images/cowork-os-6.webp" alt="Automations dashboard" width="700"> <br><em>Saved automations and scheduled work are managed from the Automations surface.</em> </p>Where It Fits
CoWork's automation model has three layers:
Workflow Intelligenceis the always-on cognitive runtime.Routinesare the primary saved automation product for instructions, targets, triggers, outputs, policy, and observability.Scheduled Tasks,Webhooks, andEvent Triggersare lower-level execution engines used directly by advanced users and as compiled backends for routines.
Task automations create task-sourced Routines. A routine can then compile to the lower-level engine that matches its trigger:
- schedule triggers compile into
Scheduled Tasks - API triggers compile into
Webhooks - event triggers compile into
Event Triggers
This keeps the task menu on the same routine-first automation path as the rest of the product while still using the durable cron, hook, and event infrastructure underneath.
Task Overflow Menu
In task view, the task title includes a three-dot overflow menu. The menu exposes actions that are supported by the current task surface:
Pin task/Unpin taskRename taskArchive taskCopy working directoryCopy task IDCopy deeplinkCopy as MarkdownFork sessionAdd automation...View outputswhen task outputs are available
Copy deeplink copies cowork://tasks/<taskId>. The app handles that URL by reopening the matching task, so copied links can be pasted into another task, a note, or an external place that can launch the CoWork URL scheme.
Add Automation Flow
Clicking Add automation... opens an Add automation modal over the current task.
Defaults come from the selected task:
name: current task titleprompt: current task promptworkspaceId: current task workspacetarget:Continue threaddescription:Created from task <taskId>plus the task deeplink- saved instructions: the edited automation prompt plus a source reference containing the original task title, task ID, and deeplink
The modal includes:
- a large prompt editor prefilled from the task
- a footer
Run inselector - a
Targetselector forContinue threadorNew task - an editable automation name control
- a schedule selector
CancelandSave- a
Use templateview with built-in template prompts
Save is disabled until the name, prompt, workspace, target, and schedule are valid. If routine creation fails, the modal shows the returned error inline and stays open.
Target Modes
Continue thread is the default. Scheduled, API, and event-triggered runs append a follow-up message to the source task, preserving the conversation context and timeline. This is the closest equivalent to Codex-style thread wakeups.
New task creates a standalone run for each automation execution. Use this when the recurring work should not mutate or lengthen the original conversation.
Worktree execution is not compatible with Continue thread. The UI prevents that combination, and lower-level worktree automation payloads force New task so a worktree run never silently targets an existing thread without the right execution context.
Run Modes
Chat is the default run mode. It creates the safest unattended automation:
shellAccess: falseallowUserInput: false
Local runs in the current workspace and enables shell access:
shellAccess: trueallowUserInput: false
Worktree is shown only for tasks with a worktree path. It is disabled for same-thread automations because a thread follow-up must run against the original task context, while a worktree automation needs an isolated run target.
Schedule Presets
The modal supports these presets:
| Preset | Scheduler payload |
|---|---|
Every 30m | { kind: "every", everyMs: 1800000 } |
Hourly | { kind: "every", everyMs: 3600000 } |
Daily | { kind: "cron", expr: "0 9 * * *" } |
Weekdays | { kind: "cron", expr: "0 9 * * 1-5" } |
Weekly | { kind: "cron", expr: "0 9 * * 1" } |
Custom | user-entered cron expression |
Custom schedules use the existing cron-expression path and are invalid until the expression is non-empty.
Templates
Use template opens a compact template grid. Selecting a template returns to the create modal and fills:
- automation name
- prompt
- schedule preset
Built-in templates cover common recurring examples:
- daily summary
- scan recent changes
- CI failure summary
- weekly update
- inbox check-in
- regression watch
Templates are deliberately small and local to the task automation modal. They are starting points for routine instructions, not separate managed agents.
Compiled Payloads
Saving calls window.electronAPI.createRoutine with a task-sourced routine payload.
For schedule triggers, the routine service creates a cron job. Same-thread schedules use:
{
runMode: "thread_follow_up",
targetTaskId,
threadAutomation: {
source: "routine",
routineId,
taskId: targetTaskId,
},
}
New-task schedules use the normal runMode: "new_task" cron path.
For API triggers, the routine service creates a webhook mapping with action: "task_message" when the target is Continue thread. The handler sends the request body as a follow-up to the target task and only includes the task ID in the response when the mapping explicitly asks for it.
For event triggers, the routine service creates an event trigger whose action carries the same run target. A thread_follow_up event trigger must include targetTaskId; invalid configurations fail instead of falling back to a new task.
Automation-specific agent settings are applied as transient run overrides. They do not overwrite the saved agent configuration on the target task.
Monitoring Results
Settings > Automations > Routines is the primary place to inspect task-sourced automations because it owns the saved instruction, trigger, target, policy, and recent routine run state.
When a task automation compiles to a scheduled task, Settings > Automations > Scheduled Tasks also shows the lower-level cron job. The panel summarizes:
- total scheduled tasks and active tasks
- aggregate run success rate
- the next scheduler wake-up and any currently running job
- jobs needing attention because their latest run failed, timed out, or needs user action
- whether a job creates a new task or continues an existing thread
Expanding a scheduled task shows:
- the latest run status in plain language
- total run count, success rate, and latest duration
- delivery state for channel-backed scheduled outputs
- latest error text when a run or delivery failed
- a run-folder indicator when the scheduler created a dedicated run workspace
- a direct
Open generated taskor thread link when available
The run-history ledger keeps recent runs together with status, duration, delivery outcome, and an Open action for each generated task or target thread. Refresh reloads scheduler history from the cron service, while Clear removes the scheduler history counters for that job without deleting task sessions.
Current Limitations
- Automations are unattended by default:
allowUserInputis false and human-input policy is effectivelynone. A prompt that requires interactive clarification should be rewritten before saving. - Worktree execution cannot continue an existing thread. Choose
New taskfor worktree-style automation. - Remote-session task views should not create local automations from the remote shadow task.
Implementation Notes
The task automation UI is implemented in src/renderer/components/MainContent.tsx.
Important helper exports:
TaskAutomationModalTASK_AUTOMATION_TEMPLATESbuildTaskAutomationSchedulebuildTaskAutomationPromptbuildTaskRoutineCreatebuildTaskAutomationCronJobCreatefor low-level scheduled-task payload coverage
The focused renderer test coverage lives in src/renderer/components/__tests__/main-content-working-state.test.ts and verifies:
- modal defaults from a selected task
- default
Every 30mschedule payload - default same-thread target
- template defaults
Localrun mode enablingshellAccess- worktree target protection
When changing this flow, run:
npx vitest run src/renderer/components/__tests__/main-content-working-state.test.ts
npm run build:react