Work Mode 24/7 — gateway is the Work daemon

One rule: Desktop / Electron closed ≠ Work stopped. The messaging gateway is the Work daemon (ADR W3).

vibeos work daemon status

That single command reports whether messaging, cron, and kanban dispatch are on — and whether you are ready for unattended Work.

What “daemon” means here

Piece	Hosted by	Role
Messaging (Telegram, email, …)	vibeos gateway	Remote steers / status / approvals
Cron schedules & monitors	same gateway process	Scheduled Tasks parity
Kanban dispatcher + Work status mirror	same gateway (kanban.dispatch_in_gateway)	Workers claim durable steps
Desktop Work UI	Electron (optional)	Inbox / approvals while you are at the screen

There is no second Work process. Closing the chat window does not pause Kanban or cron.

Honest limit: if the machine sleeps or powers off, Work pauses — VibeOS is not OpenAI’s cloud. See Honest limitations.

How to keep 24/7 (checklist)

1. Install autostart once (Linux user systemd or macOS launchd):

   vibeos gateway install
   vibeos gateway start

   Details and system-service options: Messaging Gateway.

   Hand-editable templates (placeholders only — prefer the installer above):

   vibeos work daemon examples
   # → examples/work-mode/systemd/*.service
   # → examples/work-mode/launchd/ai.vibeos.gateway.plist

   See also the checkout README at examples/work-mode/README.md. On a VPS / headless host: sudo vibeos gateway install --system. Optional Linux linger so user units survive logout: loginctl enable-linger "$USER".

   A foreground vibeos gateway run is useful for development and bounded smoke tests, but it is not 24/7 supervision: closing the terminal, logging out, or rebooting can stop it. vibeos work daemon status therefore keeps gateway: running separate from 24/7 ready: yes; the latter requires the installed service to be running as well.

Restart policy (crash recovery)

Installed units use Restart=always with a short RestartSec (typically 5s) so a crashed gateway comes back without a cloud Operator VM. That is machine-local recovery — not ChatGPT “always-on cloud.”

Host	What to expect
Linux user systemd + linger	Survives logout; still pauses on host sleep/power-off
Linux --system on a VPS	Boot + crash restart; closest to unattended overnight
macOS LaunchAgent	After user login; lid-sleep still pauses Work

Inspect templates: examples/work-mode/systemd/*.service (Restart=always, RestartSec=5). Prefer vibeos gateway install over hand-copying — it fills VIBEOS_HOME / PATH correctly.

2. Verify the Work daemon:

   vibeos work daemon status
   # or: vibeos work daemon status --json

   You want 24/7 ready: yes, gateway: running, and kanban dispatch: on. After reboot, run the same command — no manual gateway run in a terminal.

3. Optional messaging for phone pings — configure at least one platform (vibeos gateway setup). Local cron/kanban still run without Telegram.

4. Leave Desktop closed overnight if you like. Re-open Work Inbox in the morning for deliverables.

Config knobs (not env vars for behavior)

Key	Meaning
kanban.dispatch_in_gateway: true	Gateway runs the Kanban dispatcher (default)
work.sync_on_dispatch: true	After each dispatch tick, mirror WorkTask status from Kanban
work.enabled: true	Marks Work Mode active in vibeos work status

Do not invent VIBEOS_WORK_* flags for these — use config.yaml.
(VIBEOS_KANBAN_DISPATCH_IN_GATEWAY remains the existing kanban override only.)

Anti-goals

• Do not require Electron / Desktop to be open for Work to proceed.
• Do not start a separate “workd” process — extend gateway.
• Do not treat Work as cloud-only — autostart is local systemd / launchd.
• Sleeping laptop = paused Work (document the truth).

Schedules (cron)

From a Work task (Desktop Repeat daily / Monitor, or CLI):

vibeos work schedule <task_id> --daily
vibeos work schedule <task_id> --window morning   # or afternoon | evening
vibeos work create "digest" --window morning      # create + day-part cron
vibeos work schedule <task_id> --monitor [--url https://example.com/status.json]
vibeos work schedule --list                       # Work Scheduled hub (all Work-tagged jobs)
vibeos work schedule <task_id> --list

Creates a cron job with metadata.work_task_id — visible in the Desktop Scheduled hub + Cron overlay. There is no second Work scheduler.

Day-parts (ChatGPT Scheduled parity): morning → 09:00, afternoon → 14:00, evening → 19:00 local.

Monitor mode installs a delta-gate script (cron/scripts/monitor_delta_gate.py via work-monitor-*.py). Unchanged content → wakeAgent: false → agent not woken. Default cadence is every 15m (floor 5m) — not 10s polling.

Computer Use on Work cron

Background Computer Use is off by default. Config:

work:
  allow_computer_use_in_cron: off   # off | ask | allow

Policy	Meaning
off (default)	--computer-use is rejected
ask	--computer-use --confirm-computer-use required
allow	--computer-use is enough

# After setting work.allow_computer_use_in_cron: ask|allow
vibeos work schedule <task_id> --daily --computer-use --confirm-computer-use

The scheduler strips computer_use from Work cron jobs that lack consent metadata — no silent CU in the background.

Workload quotas

For gateway maintenance or a messaging-only smoke test, scheduled execution can be disabled without changing the persisted job store:

cron:
  enabled: false

Remove the key or set it back to true, then restart the gateway to resume the existing schedules.

When work.enabled: true, Work applies safe floors to existing knobs so a laptop cannot run dozens of parallel workers:

Knob	Work floor (default)
kanban.max_in_progress	3
cron.max_parallel_jobs	2
delegation.max_concurrent_children	3

work:
  enabled: true
  quotas:
    apply_floors: true          # set false to restore unset/0 → unlimited
    kanban_max_in_progress: 3
    cron_max_parallel_jobs: 2

Anti-goal: 0 does not disable workers — it falls back to the floor. Raise a positive integer to allow more concurrency.

vibeos work status          # shows floors + running/cap
vibeos work status --json   # workload.warnings (WL.work_near_cap / WL.work_at_cap)
vibeos workload             # full quota doctor

Desktop Work shell shows a warning banner when near/at the kanban cap.

Honest limitations: sleep & offline

Work Mode “24/7” means your machine stays awake with the gateway running (systemd / launchd). It is not a promise that tasks keep going in someone else’s data center while your laptop is closed.

Situation	What happens
Desktop / Electron closed	Work continues (gateway hosts cron + kanban)
Mac/PC sleep, lid close, hibernate	Work pauses — no ticks, no workers
Power off / crash	Work stops until gateway starts again
Network offline	Local cron/kanban may still run; messaging/remote steers wait
Wake from sleep	Gateway resumes; due cron jobs apply catch-up (below)

Cron catch-up (not a full backlog)

When the gateway was down or the machine slept past a job’s fire time:

• Recurring jobs (interval / cron expr) get a grace window: about half the schedule period, clamped between ~2 minutes and 2 hours.
• Inside grace → the job can still fire on the next tick.
• Past grace → piled-up missed slots are skipped; the scheduler runs once and re-anchors the next run (avoids replaying overnight every 15m fire in a burst).
• One-shot jobs have a short grace (~2 minutes class) so a tick a few seconds late still runs; after that they are not revived forever.

So: sleep is a pause, not “queue everything for later like a cloud worker.”

What we do not promise (vs ChatGPT cloud)

ChatGPT / cloud agents	VibeOS Work
Keeps running when your laptop sleeps	Paused until the machine wakes
Hosted by the vendor’s always-on fleet	Hosted by your gateway process
“Always on” without your hardware	Needs awake Mac/PC/VPS (or similar)

Anti-goal: do not claim cloud 24/7 without hardware.

For true unattended overnight work, use a machine that does not sleep (desktop plugged in with sleep disabled, or a small always-on host / VPS with vibeos gateway install --system). Verify after reboot:

vibeos work daemon status
# tips include the sleep/offline honesty line; JSON has "limitations"

Status from your phone (Telegram /work)

With messaging configured on the gateway, send /work (or /work-task) from Telegram. You get a short status card:

Work status
  running 1 · blocked 1 · done 2 · queued 0  (total 4)
  Needs attention / recent:
  ! [waiting_approval] …  …
  > [running] …  …

Command	What you see
/work	Status card (running / blocked / done)
/work card	Same card
/work inbox	Full list
/work show <id>	One task
/work create [--window morning] <goal>	Create (+ optional day-part cron)
/work schedule --list	Work Scheduled hub
/work approvals	Waiting for you (Fleet parity)
/work ready [--quick]	Preview gate
/work connectors	MCP/skills calendar/CRM setup
/work help	Full help

Same store as Desktop / CLI — not a mobile app. Gateway must be running.

vibeos work card          # same card in a terminal
vibeos work card --json

Connectors pack (email + webhook)

Practical minimum — not a full Plugins directory clone:

Connector	How
Email → Work	work.email_to_task + allowlist; self-send to gateway address OK (non-Re:); IMAP via email platform setup
Webhook → Work	Route config create_work: true (idempotent; beside create_kanban)
Calendar / niche SaaS	vibeos work connectors + skills / MCP catalog — not Salesforce-in-core

User guide: Work Mode.

Related

• Work Mode (inbox, email, browser, approvals)
• Phase progress: docs/plans/2026-07-22-work-mode-phase-w3-progress.md … w7
• ADR: docs/plans/adr-work-mode.md (Daemon = gateway; email appendix Day 39)
• Autostart templates: examples/work-mode/ (vibeos work daemon examples)
• Monitor ops: docs/ops/cron-monitor-mode.md
• Workload ops: docs/ops/workload-quotas.md
• Operator: Days 48–49 live IMAP closed 2026-07-24 (Day 38 overnight ✅; CU ✅)