Dayhand in the terminal

dayhand is two things in one command: plain commands for people, scripts and agents (dayhand add, dayhand done 3), and dayhand ui, the plan full screen in the terminal. Both use your server’s MCP tools with the key that dayhand login stored, so every change shows up in the apps at once and is signed cli in the history. Installing it: Install.

Everyday commands

Tasks are referred to by number (3 or #3), now for the now task, or their id. Dates are English phrases in your time zone from the server settings (dates). Changing three or more tasks at once asks first (or needs --yes in a script). Every command and option: command reference, also as dayhand help <command> and the manual page man/dayhand.1.

dayhand ui

dayhand ui

It opens full screen with five views: Today (a coloured plan-health line, overdue, the now task with its resume note, today, done today), the Board (to do, in progress, done), the Week (Monday to Sunday as bars, the selected day in full below) the Trash and Agents. Enter opens a task with its history, which names who made each change: app, cli or agent: <name>, so an agent’s edits stand out; details also show who claimed the work, the acceptance criteria, plan, proof and what it waits on or is blocked by.

The keys most people need:

The full list is ? in the app, dayhand help ui and the reference. The layout and keys follow vim and lazygit.

• Quick add (a) reads a date phrase at the end or the start of the line and #labels anywhere. The line below shows how it was read before Enter adds it; no date adds no day, and quotes keep words as text.
• The mouse selects and scrolls. Mouse reporting stops the terminal’s own text selection: hold Shift while dragging to select anyway, or start dayhand ui --no-mouse.
• Refresh: what is on screen is read again every 12 seconds (--interval 10 to 300), within the key’s limits of 120 reads and 60 changes a minute; R refreshes now. Without a connection it keeps the last data on screen, says so in red, and tries again.
• Colours are the terminal’s 16 ANSI colours, so your terminal theme applies.
• Language: the screens speak English, Polish, German, Spanish, French, Brazilian Portuguese, Japanese or Simplified Chinese, following --lang, then DAYHAND_LANG, then the locale (LC_ALL, LC_MESSAGES, LANG). Date phrases, the other commands, --json and error codes stay English.
• --view week opens another view first.

dayhand ui shows the plan while it is open; it has no reminders. For reminders on a computer, use the macOS or Linux app. On Omarchy, a launcher entry and a key make it an app of its own: dayhand ui on Omarchy.

Several servers and profiles

dayhand login --url <address> stores a key per server address. config.toml can name profiles and aliases:

default_profile = "personal"

[profiles.personal]
url = "https://<deployment>.convex.site"

[profiles.work]
url = "https://<other>.convex.site"

[aliases]
week = "list --due-before eow"

dayhand --profile work, or DAYHAND_PROFILE=work, picks one; dayhand week runs the alias. dayhand whoami shows which server, profile, key source and file are in use. Where the file lives and how the URL and key are chosen: config. The key itself never goes into config.toml: dayhand login keeps it in the system keychain (macOS Keychain, Windows Credential Manager, the Secret Service on Linux) or, without one, in a file only you can read (login).

For scripts

• --json prints exactly what the server’s tool returns, in a shape described by the schemas; --plain prints tab-separated rows without headers.
• Errors with --json are one JSON line on stderr, and the exit code says what to do next: 2 a usage error, 3 no or a wrong key, 4 not found, 5 the server is unavailable or the key made too many calls, 6 refused by the task’s state, 7 refused by the owner (exit codes).
• After exit 5, run the same command again with the --client-id the error names: a change is never applied twice (retries).
• dayhand never asks anything without a terminal (--no-input or DAYHAND_NO_INPUT=1 make sure).
• DAYHAND_URL and DAYHAND_API_KEY win over the stored login, so a script or an agent can use its own key (agents).