Workflows

The Workflows tab has two things: workflows, which are prompts that run manually or on a schedule, and check-ins, which send a message back into a chat on a timer.

Both do real work. They run through the official command-line tools (claude, codex) and use your plan limits, just like chatting.

Workflows#

A workflow is a prompt, where it runs, and when. Each run is a full agent turn in the background, and becomes a chat you can open and continue.

The empty tab shows Ideas for you: ready-made workflows written for the repo you work in most, and using your agents where they fit. Click one to open the editor already filled in:

Describe it, and AI plans it#

The examples follow the selected trigger. Manual offers tasks such as reviewing a PR with a URL supplied at launch; choosing one keeps the workflow manual. Scheduled offers recurring tasks and fills in the example's schedule.

New workflow starts by asking what you want, in your own words, for example "every weekday at 9, find failing tests and fix them, but ask me before changing code". Pick the folder and trigger: Manual (the default) or Scheduled, then press Enter. For Scheduled, choose the interval or day and time. The chosen trigger is kept even if the planner suggests a different schedule. You can dictate it (🎤) and attach files (📎, drop or paste): the planner is told about them, and the first step gets them.

• Who plans it: your own Claude or Codex, through its command-line tool, so it uses your plan (no API key). The Plan with chip picks which; it defaults to the one with more of its limit left. It can only look at the folder: Claude gets just Read, Glob and Grep (no commands, no MCP servers), Codex runs in its read-only sandbox.
• What it decides:
  • the steps, and what each waits for, so independent steps run side by side in waves;
  • the app, model, effort and agent for each step, only from what you actually have, with heavier work on the app with more limit left;
  • each step's permissions: read-only for steps that only read, Can run commands for running tests, linters, git or gh, Can edit files for steps that change code, with Ask me first on later steps that edit files;
  • conditions between steps and a goal to check the result against.
• Review: the plan opens in the editor with a banner explaining why it's planned that way. Change anything by hand, or type a change into the banner ("use Codex for the fix") to replan. Nothing is saved or run until you press Create workflow. Back returns to your description.
• While it plans: the card shows Context → Draft → Check, elapsed time and real activity updates. Expand or collapse Activity to see recent actions. Codex reports connection and tool activity; Claude reports its transcript activity. Private reasoning and the raw plan JSON are not shown. After three successful plans with the chosen app, an approximate range comes from its last twelve successful planning times. Slower plans are labelled; quiet periods show how long since the last update. There is no invented percentage or countdown. Planning times out after seven minutes. Cancel ends the planning process and returns to the previous stage with your text, files, trigger, folder and AI choice kept. You can change Plan with and try again. Cancelling a refinement keeps the original draft and the refinement text; it is not shown as an error. You can switch to Chats, Notes or another tab and return: the description, chosen app, attachments, error and draft stay in memory, and planning continues. A completed result waits for you in Workflows without opening the tab automatically. Starting New workflow, opening a different workflow, or explicitly going Back/Cancel replaces or closes that editor. Unsaved drafts do not survive quitting Pairbar.
• Write it yourself (top right) skips the planner and opens an empty editor.

Network access in the editor applies to Codex steps with Can run commands or Can edit files. Choose Use Codex settings (Codex default in a narrow sidebar; existing workflows keep this), Enabled for GitHub and other online services, or Disabled for offline steps. This keeps Codex's workspace file sandbox; it does not grant full access or change read-only planner/goal-check permissions. The planner can propose network access for an online task; review it before saving.

The planner's answer is checked before you see it: unknown agents, models or efforts become the defaults, a missing app becomes the other, a step can only wait for earlier steps, and there are at most five steps.

Creating one by hand#

Write it yourself opens the editor (New workflow, or Edit workflow from a workflow's page). Its top line stays put while you scroll: ‹ back, the title and Cancel. So does its bottom line: what the steps may do, Agents may run, Run once now and Create workflow (Save when editing). In a narrow sidebar, step app selection and reorder controls use separate rows, and each startup question places its answer type above Required. App choices, schedule choices, plan-limit thresholds and failure-handling choices wrap onto more rows when necessary. Settings controls move below their labels when space is limited. Below 260 points, Edit with AI sits above the attachment and microphone buttons so its label stays readable. The permissions summary wraps above the agent control so both remain readable; below 280 points the chip says Agents: Off / On.

• Name at the top.

• Names have visible labels. Workflow and step names wrap as you edit, so a long name remains readable in a narrow sidebar. Scroll the form to read a name that is taller than the available space.

• Steps, as a numbered timeline. Each step is the same composer card as a new chat: Claude | Codex, an optional step name, what it should do (it runs without you, so make the prompt self-contained), and chips:

  Chip	What it sets
  Folder	step 1 only: the repo the workflow runs in
  Agent	Claude only: run it as one of your agents
  Skill	skills it uses (see Skills in a step)
  Model, Effort	the model and reasoning effort
  Permissions	Read-only, Can run commands or Can edit files (see below)
  Same chat / New chat	a later step on the same app as the one before: continue its chat, or start fresh

  Each step’s prompt has its own scrollable text editor: scroll over the text with the wheel or trackpad to read long instructions without selecting them. Short text grows within the card; long text stays within a bounded editor and has a scrollbar. Scroll outside the text to move through the workflow page. Enter inserts a new line in a step’s prompt. The 🎤 dictates into that step's prompt, and 📎 attaches files to it (or drop files on the prompt, or paste them with ⌘V). Attached files are shown as chips with × and are passed to that step by path, after its prompt; Claude may read their folders. Finder files stay at their original paths: keep them available for later runs. Images pasted from the clipboard are saved as private PNG attachments under ~/.pairbar/attachments/. Each card has ↑ ↓ to move it and 🗑 to remove it; Add a step here goes between two steps and Add a step after the last (five at most). Moving a step sets what each step waits for back to the step before it. Between two cards, chips say what the second waits for and when it runs (see More than one step). Edit with AI on each card opens a change request for that step. Type or dictate the change, choose Edit with Claude/Codex, then Suggest changes. Review the suggested text and choose Apply; only that step’s prompt changes. Its model, permissions, files and dependencies, and the other steps, stay as they were. Try again regenerates from the current prompt. If you edited the prompt while AI was working, Apply reports the conflict instead of overwriting it. Cancel stops the request and keeps your change text; × closes it. Requests stay in memory while changing tabs, and are discarded when the editor closes or steps are moved, added or removed. Saving the workflow is still a separate action.

• Trigger: Manual starts only when explicitly requested. Scheduled reveals Every…, Daily, Weekdays or Weekly and the time on one row, then the next three runs ("Next: Mon 09:00 · Tue 09:00 · Wed 09:00"). Skip when the plan is low (Never, 10–50%, default 20%): a scheduled run is skipped when less than this share of the plan's tightest limit is left, so it never uses up what you need. Run now skips the plan-limit check; required startup answers must still be supplied.

• Goal: what success looks like, and Check the result against the goal (see Goal check).

• When things go wrong: Fix problems during a run, Use the other app when a plan runs low, and After repeated problems: Nothing / Suggest a fix / Small fixes (see When things go wrong).

Rows say what they do in one line; hover or click ⓘ for the details.

The bottom line:

• What the steps may do, in a few words ("2 steps can edit · 1 asks first"); hover it for each step's.
• Agents may run: Off / On (see Agents may run this).
• Create workflow / Save (⌘↩) is off until it can be saved, and says why under it ("Write what step 2 should do", "Step 3: type the word its condition looks for", "Write the goal to check against").
• Run once now saves it and runs it now, like Run now. When it has startup questions, it opens the answer composer first.

Cancel (or Esc) closes the editor, asking first when you changed something.

Permissions#

Each step has one of three levels. Pick the least the step needs.

• Every level is an explicit mode, so your own Claude defaultMode and allow rules never widen it, and denied tools win over your allow rules.
• Can run commands is not read-only. Commands can change files themselves: a test run writes caches and coverage, a build writes its output, git checkout or a script can rewrite anything. Use it in a clean checkout or a worktree, and say in the prompt what it must not do (for example "don't push, don't post").
• Codex has no "commands but no edits" mode. Its sandbox either runs commands read-only or lets them write. A Read-only Codex step may still start commands, but they can't write anything, so most test runs and builds fail. Can run commands is the workspace-write sandbox, the same as Can edit files: only the prompt keeps it from editing.
• Ask me first is turned on by itself when a later step is set to Can edit files, not for Can run commands.
• The planner, the goal check and the doctor always only look, whatever the steps may do (see below).

More than one step#

Add a step after this adds another prompt that runs when the one before finishes, for example check → fix → review. Up to five steps.

• What it waits for: the first chip on the arrow before a step. By default a step waits for the one just before it. Pick several steps, or At the start, and steps waiting for the same thing run side by side. Cards say which Wave they're in, and the workflow's page groups side-by-side steps together.

• Names: each step can have a short name, used on the workflow's page, in runs and in notifications.

• Each step picks its own app and agent, so one workflow can use Claude for one job and Codex for another. Each has its own model, effort and permissions chip (Read-only, Can run commands or Can edit files).

• Same chat or new chat: a step on the same app as the one before continues that chat, so it knows everything the step before did. A step on the other app, or one set to New chat, starts a fresh chat and gets the previous reply as input.

• When it runs (the chip on the arrow between steps):

  • Then: always.
  • Only if it said WORD or Only if it didn't say WORD: checks the last lines of the latest reply. Uppercase markers containing an underscore, such as REVIEW_READY, must be the entire final non-empty line (plain, bold or backticks); mentioning or negating a marker does not satisfy the condition. The step before is told to end with that word when it applies. A skipped step passes the reply before it on to the next step.

• Ask me first: the run pauses before that step. You get a notification with Run it and Stop; the run's page shows the same buttons, with the reply so far. When two steps wait at once, each has its own notification and its own buttons: Run it runs only the step it names, never another one that's waiting. Choosing Can edit files for a later step turns this on too. A run waiting for you survives quitting Pairbar, and stops by itself after 12 hours with no answer. A step that's running when you quit Pairbar is stopped (with anything it started) and shows as failed.

• Plan limits are checked before every step, not only the first. A step whose app is low is skipped and the next one still runs.

Skills in a step#

The Skill chip on a step (the first one's too) picks skills from your Skill library for it to follow. The menu lists first what the step's app loads in the workflow's folder, then your skills it can't see there.

• When the app can load it there, the step's prompt starts by asking for it: on Claude, "Before you start, use the review-method skill (Skill tool) and follow it for this task."; on Codex, "Use $review-method for this task."
• When it can't (a Codex-only skill on a Claude step, a Claude skill on a Codex step, or a Codex skill whose name two folders share, so $name wouldn't resolve), Pairbar includes the skill's text instead, framed with where it came from and its hash:
  • Claude: in its system prompt (--append-system-prompt-file, a private temporary file deleted after the run), with read access to the skill's folder (--add-dir), so it can open the skill's other files;
  • Codex: at the top of the message (Codex has no such option, and its --add-dir would let it write to the folder). Claude's ${CLAUDE_SKILL_DIR} and $ARGUMENTS are filled in. A skill that runs commands when it loads in Claude is included with a warning that Codex sees the commands, not their output.
• Pin these versions (in the chip's menu) saves the skills as they are now, in ~/.config/pairbar/skill-snapshots/<sha256>/. If a pinned skill changes later, the step keeps using the saved version (by including its text) and the chip turns orange. The workflow's page then shows A pinned skill changed: which skill, in which step, Review changes (the lines of its SKILL.md that differ from the pinned version, marked with + for additions and - for removals). The comparison shows a changed-line count and scrolls independently; it does not stop after 200 changes. If either file exceeds 4,000 lines, the diff marks that comparison limit and shows both full versions below it. Update pin saves the current version and pins the step to it; Undo last change puts the old pin back. Review and update actions wrap in narrow sidebars. The workflow's row in the list says "a pinned skill changed" too. Using a saved skill version means a skill that's uninstalled but pinned keeps running from its saved version; one whose saved version is gone would fail the step. A pinned skill is unavailable explains the recovery. If an installed copy exists, Review current version shows its full SKILL.md before Update pin saves that version; the missing old version cannot be compared or recovered by updating. If the skill is also uninstalled, Edit workflow opens the affected workflow so you can remove or replace the skill, or you can reinstall it first. Pin the skills an unattended, scheduled workflow uses; leave them floating when you want your edits to apply at once. Saved versions no workflow pins any more are removed at the next launch.
• An agent's skills (see Agents) are added to a step that runs with that agent.
• A skill that's gone (and has no saved version) fails the step with "Skill <name>: …" instead of running without it.
• A step's permissions still decide what it can do: a skill that allows Bash gets no Bash in a read-only step.
• Describe it can pick skills for steps too: the planner is told your skills and which app loads each in the folder, and only names from that list are kept (at most three per step).

Goal check#

The Goal section says what success looks like. With Check the result against the goal on, a last step (read-only, on whichever app has more limit left) reads what every step reported, looks at the folder if it needs to, and ends with GOAL MET or GOAL NOT MET.

• If it isn't met: Tell me — the notification says the goal wasn't met, and why.
• If it isn't met: Try once more — the steps that change files (or, when none do, the last ones) run again with what the check found, then the check runs again. It tells you either way after that.

The run shows the check's verdict as its last line, with Open chat when the check has a saved chat. The check only looks: on Claude it gets just Read, Glob and Grep; on Codex the read-only sandbox.

When things go wrong#

Each workflow has a When things go wrong section in its editor. All three layers note what they did in the run, so nothing happens silently.

1. Health. The workflow's page shows how the last 10 runs went: Steps OK (runs whose steps completed), Goal met (checks that returned a verdict), Typical time (median duration), and Limit skips. Hover over the figures for their meaning. These figures wrap into more rows in narrow sidebars. A failed check or missing verdict is called out separately and does not count as a confirmed goal result. It flags patterns:

• a step that failed the last two runs or more;
• the goal missed twice in a row;
• a step that its condition skipped in every one of the last five runs (maybe it can go);
• three or more runs skipped for plan limits;
• a run that took over three times as long as usual.

A notification goes out when a new flag appears, not on every run.

2. Fixes during a run (Fix problems during a run, on by default; rules, no AI):

Each fix shows under its step in the run, for example "Retried on Claude's default model: opus wasn't available".

3. The doctor (After repeated problems). When a step fails twice in a row or the goal is missed twice, a short planning chat (your own Claude or Codex, read-only) reads the recent runs and proposes a change to the workflow: a clearer prompt, another model or effort, a condition, a schedule, or removing a useless step.

• Suggest a fix (default): the workflow's page shows the suggestion — why, each change in plain words, and every rewritten prompt in full (before and after) — with Apply and Dismiss, and you get a notification. Long before/after prompts scroll separately within the comparison, so they remain fully readable without pushing the actions many screens away. Short prompts keep their natural height. In narrow sidebars, the suggestion uses the card’s full width for its explanation and prompt comparisons; its date and action buttons wrap separately. Apply changes only what the doctor changed: edits you made to the workflow since it looked are kept. A Fix applied confirmation offers Undo on the workflow page. If you edit it again, that shortcut refuses to undo a different change; use Undo last change in the menu instead. Dismiss confirms that the suggestion was removed.
• Apply small fixes: a change of only models, effort or schedule is applied by itself (at most once a week), shown with Undo. A schedule that would run it more often is never small. Anything bigger still waits for you.
• Do nothing: only the health notifications.

The doctor never adds steps, never raises a step's permissions (read-only < can run commands < can edit files; it may lower them), never turns off Ask me first, never turns on the goal check, and never changes the folder. The run history it reads was written by the steps (and whatever they read), so it gets it as untrusted data, apart from what you asked for, and only looks at the folder (Read, Glob, Grep). It runs at most once a day per workflow; Check it and suggest a fix in the workflow's ⋯ menu runs it now.

Undo: every change — your edits in the editor, an applied suggestion, a change the doctor made by itself — keeps the version before it. Undo last change in the ⋯ menu goes back one (the last 10 are kept). Restoring confirms Previous version restored. Action confirmations and save errors are visible at the bottom of Workflows, above the tab bar; a save error is not replaced by a success message. Save failures show a short headline with Details for the full diagnostic and Copy details. In narrow sidebars, notice actions move below the headline so the text stays readable.

Agents may run this#

With Pairbar's tools installed, a Claude or Codex chat can run one of your workflows (run_workflow, or the pairbar:workflow skill: "run the morning triage workflow for PR #42"). By default each run waits for your approval in Pairbar. In the editor, the Agents may run chip at the bottom lets chats run this workflow without asking, within the agent budgets. It's off for every workflow to start with, and only you turn it on: a planned draft and the doctor never do.

A run a chat started is an ordinary run, with these differences:

• the chat's note (a PR number, a branch) is added to the first steps, framed as another chat's words, not your instructions;
• the plan limit still applies (it isn't Run now), and Ask me first steps still wait for you;
• a chat can't run a workflow whose steps may do more than it may itself (a Claude chat in plan mode can't run one that edits), and when Pairbar can't tell what the chat may do, a workflow that runs commands or edits is asked even if it's marked;
• the run says "Started by Claude chat “…”" on the workflow's page, and the chat gets each step's outcome and the last reply back.

A chat can also ask Pairbar to draft a new workflow (propose_workflow): the planner runs as with New workflow, the card says which chat asked, and the editor opens with the draft. Nothing is saved until you press Create workflow.

What happens when it runs#

• Claude: claude -p runs the prompt in the folder. When it finishes, Open imports the chat into the Claude app.
• Codex: codex exec --json runs it; the thread is the one its first event names. The thread appears in Codex and in Pairbar with a workflow label.
• Skills: asked for by name, or included as text (see Skills in a step).
• Between steps: a reply is passed on as it is (quotes, code and JSON intact), framed as information rather than instructions. A reply longer than 20,000 characters keeps its end and says how much was cut.
• Notification: you get one when it finishes; clicking it opens the chat.
• When it can run: only while Pairbar is running. A run missed while the Mac was asleep happens once when it wakes, not once for every missed time.
• New or rescheduled: a new or rescheduled workflow waits for its next time rather than running immediately.
• One run at a time: a scheduled run doesn't start while another run of the same workflow still has a step running or waiting for you (even one that has already failed), and Run now is off meanwhile.
• Editing while it runs: a changed prompt is used by steps that haven't started yet. Adding, removing or reordering steps fails the run in progress ("The workflow's steps changed since this run started"); nothing already done is blamed.
• Deleting while it runs stops what's running, quietly.

The workflow page#

Click a workflow in the list to open its page.

At the top (it stays put while the page scrolls):

• its full name, wrapping when needed, the schedule in plain words and when it runs next ("Every weekday at 9:00 · next Monday at 9:00", or "Paused · every weekday at 9:00");
• how the last run went and when ("Last run: failed at step 2 · yesterday"), with Open chat for that run's latest chat;
• Run now (skips the limit check; off, as Running… while it runs or Waiting for you while it awaits approval), Edit, Pause / Resume, and ⋯ with Duplicate, Check it and suggest a fix, Undo last change and Delete… (it asks first; its run history goes too, the chats it made stay in Claude or Codex). Actions keep their labels and wrap onto more rows when necessary. The ⋯ button is named Workflow actions on hover. Its menu can extend beyond the sidebar to show the full check-up action and the reason in Undo last change.

For a manual workflow or one with startup questions, Run now opens Before you run at the top of the scrolling page. Answer the required questions and optionally add instructions or files, then choose Run now in the form. Additional instructions · Optional stays visible above the text, including after you type. The form scrolls with the page, keeping its actions reachable in short windows. Its Cancel and Run now buttons wrap onto separate rows when the sidebar is narrow. Cancel closes it and preserves the inputs for reopening.

Settings, as chips you can hover for what they mean: the folder it runs in, the apps its steps run on, the limit rule ("Skips under 20% limit": skipped when less than 20% of your plan's limit is left; Run now skips the limit check), and, when set, the goal check and Agents may run this. A one-step workflow also shows its agent and permissions.

Steps, as a timeline: a number on a line, and a card per step with its app and agent, its name, its permissions (Read-only, Runs commands or Can edit; hover for what each allows), its prompt and how it went the last time it ran. A prompt longer than three lines fades out with Show more; it opens inside its own card and pushes the steps below down (click the faded text to open it too); Show less closes it. Long words and paths wrap. Between two cards it says what the second one gets and when it runs: "Gets step 1's reply · only if it said BLOCKING", "runs alongside step 2", "asks you first". A goal comes last.

The page also shows how the workflow has been doing, a pinned skill that changed, and the doctor's suggestion (see When things go wrong).

Runs, newest first: the last 10, then Show all. Each run says how it's going or how it went ("Running · step 2 of 5", "Done", "Failed at step 2", "Waiting for you", "Skipped", "Stopped"), when it started (hover for the full date), how far it got (a bar and "2/5"), how long it took, and offers Open all N chats (or Open chat), Stop run while it runs, and Re-run once it's over.

The goal check shows its result and, when its chat was saved, Open chat for that chat. A failed check keeps the steps’ completed status but labels the run Done · goal check failed and shows its error details. A reply without a verdict shows Done · goal not confirmed with a neutral question-mark icon; it does not count as a confirmed success or a negative verdict. If a failed check has neither diagnostics nor a saved chat, its message points to Re-run instead of asking you to open a missing chat. Even a one-step workflow shows Checking the goal while the check runs.

Each step of a run is a row with its state in words ("Working · 3m 12s", "Done · 4m · +24 −3", "Failed · why", "Skipped · why", "Waiting for you", "Not started"), its app and agent, the first line of its result, and what self-healing did as a small badge ("Ran on Claude: Codex's plan limit was reached"; hover for more).

• Click a step (or press Return): a step that has run, or is running, opens its chat in Claude or Codex. A step that hasn't started shows its prompt and what it'll get.
• Hover a step (or press Space, or its eye button): a preview of what it's doing now (the tool it's in, such as "Bash · npm test", and the last lines it wrote), how long it's been at it, the files it changed (+/−), with Open chat, Copy (its latest reply), Stop run while it runs and Retry from here when it failed. The latest activity and reply are shown once when they contain the same text. For a step that hasn't started, the preview shows its prompt and what it'll get. Long prompts and failure diagnostics scroll within the preview; the full text stays readable and selectable while its actions remain below. Long tool errors keep their opening cause and final diagnostics, with […] marking omitted output. Previously saved errors retain the text saved at the time.
• ↑ ↓ move between a run's steps; Esc closes the preview.
• A failed step shows its error, open, and Retry from here, which runs it and the steps after it again, keeping the replies before it. Steps in the same wave run at the same time; a failed step stops what waits for it, while steps already running finish. Error details use a smaller indent in narrow sidebars, and Retry from here wraps rather than cutting off its label.
• A step waiting for you shows the reply before it with Run it and Stop here. Long replies scroll inside their own text area so you can read and select the full reply before approving. These buttons wrap onto separate lines when space is limited. In a narrow sidebar, preview and chat actions move below the step summary so its title stays readable. The disabled launch button says Waiting for you while the run awaits approval.
• Skipped runs say why, for example "Only 9% of Codex's limit left". Stopped: you stopped it, or nobody approved a step within 12 hours. Stop ends the running step's process (and anything it started), drops a retry that was waiting, and starts nothing more. Health counts a stopped run as neither a success nor a failure.

Workflows and their history are stored as readable JSON in ~/.config/pairbar/: workflows.json, workflow-runs.json (the last 300 runs), heartbeats.json (check-ins), workflow-proposals.json (the doctor's suggestions) and workflow-versions.json (earlier versions, for Undo). The folder is private (0700) and each file is written whole and private (0600). A file that doesn't read back (a hand edit gone wrong, or one written by a newer Pairbar) is never overwritten: it's renamed to <name>.corrupt-<date>, Pairbar says so, and starts that list empty.

Check-ins#

A check-in sends a message back into a chat on a timer, until it's done. It's for babysitting: "check CI; fix it if it's red; say DONE when it's green".

⋯ → Check in every… (K) on any chat:

• Codex: the message is queued even mid-turn.
• Claude: Pairbar waits until the chat isn't working.

A chat can also set up a check-in on itself (schedule_checkin, or the pairbar:babysit skill: "keep an eye on CI"), with your approval: every 10, 15, 30 or 60 minutes, up to 24 times. You can allow a chat's check-ins for good when you approve the first one. It never replaces a check-in you set up. Such check-ins say "set up by the chat" in the list, wait while agent actions are paused, and end with Stop all agent-started chats. See Agent actions.

A green ⟳ on the row shows a check-in is active. Active check-ins are listed at the bottom of the Workflows tab with Stop. You get a notification when one stops, or when a message couldn't be sent. Hiding a chat keeps its check-in; it ends only when the chat is gone.

From notes#

Notes can prepare a disabled read-only workflow draft with an immutable feedback package. Review the draft before running it. See Notes.

Manual workflows and input for a run#

Choose Manual under Trigger for reusable tasks such as reviewing a PR. These workflows never run from the timer, even after sleep or restart. Existing scheduled workflows keep their schedules. Scheduled reveals Every…, Daily, Weekdays and Weekly.

On a manual workflow’s page, or any workflow with startup questions, Run now opens a small input composer. Paste the PR URL, add instructions, dictate or attach files, then choose Run now to confirm. Additional instructions are optional, belong to this run only, and are saved in run history and passed to its steps, including retry attempts. Re-run reuses that run’s input and files. It does not modify the saved workflow prompt. Cancel starts nothing. To run from the editor, use Run once now; startup questions are collected after saving.

In fields with a paperclip, ⌘V or ⌃V pastes screenshots (Coming Soon)/images as attachments as well as files copied in Finder. Plain text still pastes normally. Up to ten files can be attached.

Startup questions#

In the editor, Startup questions sits above the steps. Without questions, it shows a compact Add question entry. Choose it, name the Question (for example, GitHub PR URL), choose Text or URL, and leave Required on when the run needs an answer. The question and optional Default answer have visible labels; long question names wrap. You can remove a question or provide a default. URL answers must be complete HTTP or HTTPS links; Pairbar does not fetch or verify the target during validation.

Run now shows these questions before starting. Required blanks and invalid URLs disable confirmation. The first answer field receives focus. Cancel starts nothing and keeps your answers for reopening; switching pages also keeps the draft while Pairbar is running. Unsaved launch answers are not recovered after quitting.

Answers belong to that run, appear in its history with the original question names, and are passed as named data to every step, including retries. Re-run reuses answers for unchanged question IDs; new required questions must be answered. Additional instructions, dictation and attachments remain available alongside the questions.

Scheduled runs use default answers. Without valid required defaults, they record a skipped run and start no step. Agent-started runs also require valid defaults; otherwise the agent receives an explanation and must ask you to launch it in Pairbar. For a different PR URL each time, choose Manual and leave the required URL’s default empty. AI replanning preserves existing startup questions; configure new questions in the editor.

One-time planning chats#

Workflow planning, replanning, AI step editing and the workflow doctor use one-time helper requests. Codex helpers run in ephemeral mode, without saving a resumable chat in Codex history. Claude helpers keep their transcript for the planner’s live progress and are automatically hidden from Pairbar’s chat list, including after import under a desktop chat ID. Hidden transcripts remain available with Show hidden chats → Unhide. This does not hide or discard chats produced by the workflow’s actual steps.