Task Power Features

The task page includes tools for branching, recovering, sharing, and reshaping work after a task has already run. Use these features when you need to compare another approach, recover from a bad turn, or turn useful task context into future work.

Use Side Chats to ask about the task's conversation without interrupting the agent or adding to the task's history.

Runtime controls through Ask

Ask CoderFlow can stop or interrupt a running task, resume a paused follow-up queue with entries, and start, stop or restart its configured app server while the container is running. Allow Actions must be on, and every runtime control needs your confirmation, even when auto-apply is on. The card identifies the task and the consequence.

Stop leaves queued follow-ups paused, and Interrupt pauses them unless you ask to send them. Stopping or restarting an app server interrupts its users. Ask never repeats a control whose outcome is unknown.

Queued follow-ups

A follow-up you send while the agent is working waits in the task's follow-up queue until the current turn ends. The queue panel (above the reply box, or in the conversation view) lists the waiting follow-ups in order. You can edit a follow-up you queued (its text, attachments and model), remove any follow-up, and send the queue on when it is on hold.

To give the list less room, select the Queued follow-ups heading. The list collapses to that one line, which keeps the count, the status and the queue's buttons; select the heading again to open it. The Scheduled list collapses the same way. Your browser remembers which lists you keep collapsed.

Ask CoderFlow can replace the text of one queued follow-up, or remove one, with the same rules as this panel. Allow Actions must be on, and each change needs your Confirm, even when auto-apply is on. The card shows the follow-up's place in the queue and its text, and says there is no Undo. Confirm changes nothing if the follow-up changed, was sent, was removed or moved since the card was prepared; ask again for a fresh card. For attachments, model settings, scheduled follow-ups, Send now and rewinding, Ask offers an Open in the follow-up queue hand-off button that opens this panel on that follow-up. A change made through Ask shows at once in your other tabs and in every open page of a running task. Another person's open page of a task that is not running shows it within about 15 seconds.

Sharing Tasks

Task links are normal CoderFlow links. They do not bypass authentication, and copying a link does not change who can see the task.

Use the Share button in the task header to copy:

• Copy Task Link - a direct link to the current task
• Copy Task Group Link - a link that opens all loaded variants in the group
• Copy Task ID - the task identifier for chat, tickets, or support notes

The task page also keeps its URL in step with what you are looking at. Selecting a variant in a group, or opening the AI Review dialog on a particular judgment, is recorded in the address bar, so copying the URL at that moment sends someone to the same place rather than to the top of the task. Browser Back closes the review dialog instead of leaving the page.

Who can use a task

Every task has one of three sharing states. Whether a new task starts private or shared depends on its environment's default and, where the launcher offers the choice, on what you picked at launch. After that, sharing is changed on the task page: open More actions and choose Sharing....

The dialog shows the current state and these choices:

• Private - only the task's owner and people with elevated task permissions in the environment can see or open the task.
• Shared (view only) - teammates who can view tasks in the environment can read the conversation and results and post comments. They cannot run, change or approve anything.
• Shared - teammates in the environment can open the whole task and work in it as far as their permissions allow. Teammates who can only view tasks there see its view-only page.

Pick a choice and select Save. Nothing changes until you do, and the dialog returns to the saved state if the server refuses the change.

The task's owner can change its sharing with the tasks:change permission. Anyone else needs tasks:change_any on the environment; the Sharing... item is hidden from people who have neither.

When a task is private:

• The owner can still view and change it.
• Environment admins with tasks:view_any, tasks:change_any, or related _any permissions can still operate on it.
• Other environment members no longer see it in task lists or task stats, and direct links return a permission error.

When you choose Shared, the dialog warns that people who can run commands or direct the agent in a shared task may be able to read credentials available to the task and use its connected accounts, including your personal credentials. Share control only with people you trust with that access.

Shared means you trust these teammates to act as you. Follow-ups they send run the agent with your credentials, and with the permission to execute tasks they can run commands, open VS Code and the app server, and with terminal access the terminal, all with your credentials. To show your work without that, use Shared (view only).

Teammates whose only task permission in the environment is to view tasks (the Viewer role) never get that reach: on a shared task they see its view-only page, exactly as described in Sharing a task view only, with a banner that says the task is shared and that their role lets them view it only. Its tile shows View only for them. Everyone who can change, run, approve or delete tasks there keeps the full task. See Shared tasks and people who can only view.

A shared task started before CoderFlow kept a record of the credentials it was given cannot have its conversation checked for them, so its view-only page says the conversation and results are not available, and its comments are not shown to those teammates either. Choose Shared (view only) once, which records them, and then Shared again.

Sharing a task view only

Shared (view only) lets teammates follow a task without being able to operate it. Use it when the outcome is worth showing but the task holds credentials, files or tool output you do not want to hand over.

Viewers are the people who hold tasks:view on the task's environment. They see:

• Your prompts and follow-ups, and the agent's final replies
• The summary
• The saved changes: the list of changed files and each file's diff
• Test results, as passed or failed
• Comments

Withheld from viewers: tool calls and their output, logs, files, attachments and screenshots. That includes the output of tests, the file browser, the terminal, VS Code and the app server.

Before you save, select Preview as viewer. It reads the task the same way a viewer's page does and shows exactly what they will receive, including the name they will see. Read it: redaction has limits, listed below.

• Preview as viewer - opens the redacted conversation, summary, changed files, test results and comments in a dialog. Previewing changes nothing.

The dialog also warns you when the task has secret values shorter than six characters, because values that short are not redacted. The warning appears after you save view only, when you open the dialog on a task that is already view only, and in the preview.

Some tasks cannot be shared view only. For reviews, judge tasks and Portal tasks the dialog turns the choice off and gives the reason. Objectives have no sharing choice at all: Sharing... is not offered for them.

A task that is shared view only shows a View only badge on its dashboard tile and beside its status on the task page, for you and for viewers.

What a viewer gets

A viewer sees the task's tile in task lists, with the View only badge, a name with secret values removed, the status, the owner and the dates. Opening it shows the view-only page in place of the task page:

• A banner that says the task is shared view only and names what is withheld.
• Conversation: prompts, follow-ups and final agent replies, oldest first.
• Summary: the task's written summary. When there is none, the closest saved text is shown instead (usually the agent's latest reply), with a note saying so.
• Changed files: the files in the saved changes, grouped by repository. Select a file to show its diff.
• Test results: each saved test's name and whether it passed. Test output is a log and is not shown.
• Comments: viewers can read comments and post their own, with @ mentions of teammates who can see the task.

A viewer can also add the task to their own Pinned list with Pin on the banner, and remove it with Unpin. Only their own list changes; your pin is untouched. The pin menu on the task's dashboard tile works for them as it does on any tile, including snooze, and the banner says when their pin is snoozed. The tile offers nothing else: no rename, no selection for bulk actions, no container control and no dragging.

That is all a viewer can do. They cannot send follow-ups, rename the task, edit or delete a comment (their own included), attach files, open files, logs, the terminal or VS Code, export, fork or resubmit the task, start a review, or approve its changes. Every other request about the task is refused.

When a viewer opens a view-only task together with other tasks, actions on all the open tasks leave the view-only task alone. A rename from the header and a winner pick apply to the tasks the viewer can open in full. Delete All counts and deletes only the open tasks the viewer may delete: their own, or any task if they hold tasks:delete_any. A teammate's shared task they have open is not deleted, and on a task they may not delete neither More actions nor the Delete key offers to. A variant group that has a view-only member cannot be changed by a viewer of that member: its tabs cannot be reordered or removed from the group, it takes no winner or loser mark, and it cannot be renamed or regrouped from the task page. The same applies when a member of the group is private.

The page shows a long conversation honestly. A very long message is cut and marked, with its full length. When the conversation is longer than the view carries, the page shows the most recent part and counts the earlier messages that are not shown.

The page keeps itself up to date. Viewers get no live stream of the agent's work, so there is nothing to watch while a turn runs; the page checks the task about every 15 seconds while it is visible and reads the new reply when a turn finishes or a follow-up is sent. New comments from other people arrive with the same check, so they can take a few seconds to appear.

• When access ends, because you made the task private or the viewer's access to the environment changed, the page is replaced with This task is no longer shared with you and the conversation and results are removed from it. The same happens when the viewer signs out, in that tab or another one.
• When the server cannot prepare the redacted view at that moment, the page says the shared view is temporarily unavailable and offers Try again. A page that already shows the task keeps what it has and says it may be out of date.
• When you switch the task to Shared, a viewer's open page loads the full task page.

What else changes

• A child task created while its parent task is view only is private, whatever the environment's default or the request asks for. Child tasks that already exist keep their own sharing; change each one where needed.
• Reviews and judge tasks of a view-only task are private, as they are for a private task.
• Connections a teammate already has open to the task (VS Code, terminal, app server) are checked again when a shared task becomes view only, and close unless that teammate holds the matching _any permission.
• Notifications work as they do for a private task. In addition, a viewer who is @-mentioned in a comment is notified with the task's redacted name and a link, without the comment's text.
• The CLI, the VS Code extension and MCP treat a view-only task as private: its owner and people with _any permissions can use it there, and viewers cannot. The view-only page is in the web interface only.
• People with the _any task permissions on the environment keep full access, exactly as on a private task. View only does not limit them.

Limits of redaction

Redaction replaces text with [redacted]. Know what it does and does not catch before you share.

It replaces secret values the server knows:

• Environment secrets and personal secrets
• AI provider keys and tokens
• Git credentials
• Container and MCP tokens
• Connection credentials

This includes values that were rotated or removed after the task ran. For a task started before the release that added view-only sharing, it covers the values that are current when you share the task, not older ones.

It also replaces:

• The base64, URL-encoded and JSON-escaped forms of those values
• Private key blocks
• Authorization headers with a Bearer or Basic credential
• JSON Web Tokens (JWTs)

It does not replace:

• A value created inside the container, or typed into a prompt. The server never held it, so it cannot recognize it.
• A value shorter than six characters.
• Other transformations of a known value: hex, double encoding, or a multi-line value that was re-indented or had its line endings changed.
• An unknown bearer token shorter than 20 characters.
• A secret shown in an image.

These gaps are why tool output, logs, files and attachments are withheld from viewers entirely. They are also why you should read Preview as viewer first: a password you typed into a prompt will appear in the conversation.

Two more limits:

• If you switch a task from Shared to Shared (view only) while a teammate's request is already in progress, that request can still complete.
• The task name on a viewer's tile is a redacted copy. It is saved when you set view only, when you rename the task, and when the view is read, so a secret added to the known values later is removed from the name the next time one of those happens.

Export and Import Tasks

Sharing a link works only for people who can reach the same server. Export packages a task into a portable ZIP file instead, so it can be archived or recreated on a different CoderFlow server.

Exporting

Open More actions on the task page and choose Export Task..., or run coder export. Exporting requires permission to view the task.

The package contains:

• The task's persisted output and activity history
• Task metadata, including its name, environment, agent, and instructions
• Container logs
• A workspace delta: the files the task added or modified, plus the list of paths it deleted

Runtime-only server material, such as generated MCP configuration, is deliberately left out.

What the workspace delta carries

The delta is derived from git's view of each repository in /workspace - the same view that produces the changed-files list in the approve dialog. Because it inherits each repository's .gitignore, installed dependencies such as node_modules and the .git directories themselves never travel with the package. A representative export shrinks from hundreds of megabytes to the size of the source the task actually touched.

Two consequences are worth knowing:

• Files in /workspace that no repository owns are not carried. They are environment scaffolding rather than a task's result; the manifest records them if you need to check.
• Content that git ignores is not carried, even when it matters. If a task's result depends on an ignored file, export with the full workspace instead.

There is no per-file size limit. A file the task changed is carried whatever its size - a cap that dropped one large file and shipped the rest would produce a package that looks complete and is not. The delta as a whole is bounded, at 256 MB and 20,000 files; a delta over either bound is not carried at all and the export says why, rather than being quietly truncated to fit. What a capture could not carry is recorded in the manifest whether or not an archive came out of it.

If a repository the changed-files list names cannot be read in the container, the delta is refused rather than shipped without it - a partial capture that looks complete is worse than none. The export names the repositories involved so you can retry or fall back to a full workspace.

coder export --workspace=full opts back into an exact archive of the entire /workspace, and --workspace=none omits the workspace entirely.

warning

An export contains your task's source changes and stored metadata. Treat the file with the same care as the source code it contains, and check what it holds before sending it outside your organization. A full-workspace export additionally contains everything else in /workspace.

Capturing a workspace depends on the task's container still being retained (see Container Lifecycle) and, for a delta, still running - the capture reads git inside it. When no workspace can be captured, the export still succeeds with output, logs, and metadata, and records why the workspace is absent. A task that was itself created by an import keeps its stored snapshot, so exporting and importing the same work repeatedly does not lose the workspace.

Importing

Open the quick actions menu on the home page and choose Import Task..., then select the .zip file. The package decides what you get, whichever view you started the import from: an exported objective comes back as an objective, a finished task comes back finished and ready to continue, and anything captured mid-run lands staged and waits for a prompt. Pinned tasks come back pinned.

The CLI chooses explicitly with --mode, and also accepts a plain local workspace directory, which it packages for you before uploading:

Mode	Result
preserve (default)	Whatever the package was: an objective as an objective, a finished task as a finished task, anything else staged.
objective	A reusable objective with no container, ready to launch later.
staged	A staged task with its container prepared and the workspace applied, paused before the agent runs.
running	A task that starts work immediately, queueing first if no agent slot is free.

CoderFlow imports into the environment named in the package, falling back to your default environment and then to the server default; --environment overrides all of them. The import is refused if the environment that resolves does not exist on this server, or if you do not have tasks:create permission for it. A plain workspace directory carries no package metadata, so it depends entirely on those defaults - name an environment explicitly to be sure it lands where you intend.

How the workspace is applied

A delta is merged into the workspace the destination environment set up for itself: the carried files are written over what is there, the deleted paths are removed, and everything else - dependencies, unrelated sources - is left alone. Nothing is wiped.

The two halves apply together or not at all. Deleted paths are resolved before any of them is removed, so a path that would escape the workspace refuses the whole list rather than being discovered halfway through; and if any declared deletion cannot be completed, the carried files are not written and the task fails instead of being handed over as ready. A workspace missing half of a delta is neither the task's result nor the destination's own state.

A full-workspace package, including one exported by an older CoderFlow version and any plain workspace directory, still replaces /workspace outright. That is what a full archive means: it is the whole workspace, so overlaying it would leave stale files behind.

A delta records the base commit, remote, and branch each repository was exported from; remote URLs are stripped of any credentials before they are written to the package. When the task committed its work, the recorded base is the point that work branched from rather than the container's own HEAD, so a destination sitting on the original base still matches. When the destination differs on any recorded field - including when it reports nothing at all, such as a repository with no commits - the import reports the difference and applies the delta anyway, because the package carries whole files rather than a diff and applies the same either way.

Pass coder import --require-matching-base to refuse the import instead. The check compares against repositories that only exist once the destination container has cloned them, which happens after the import is accepted, so a refusal appears as a failed task rather than a failed command. The task's error names the repositories that diverged.

Uploads are limited to 2 GB by default. A server admin can change this with the TASK_IMPORT_MAX_FILE_SIZE_BYTES environment variable.

Fork a Task

Forking creates an independent task from a finished task's current state. Use it when you want to continue from the same context without changing the original task.

1. Open a task that is completed, failed, or interrupted.
2. Open More actions.
3. Choose Fork Task.
4. Choose the AI provider and the context for the fresh agent session, then confirm the fork.

The fork gets its own task ID, container, task history, branch selections, IBM i build library list, attachments, and copied workspace state. If the original task container is still running, CoderFlow captures the live workspace state; otherwise it falls back to saved task state when available.

Lineage links work in both directions. The fork page shows its Forked from link, while the original task page lists its direct Forked tasks with links back to each accessible fork. For a heavily forked task, the first five appear initially; choose +N more to show the rest.

Choosing fork context

The fork dialog offers two ways to carry the source task's context into the fork's first follow-up:

• Full task history (default). The fork replays the original instructions and every prior follow-up verbatim. Best when exact wording, decisions, and constraints matter.
• Generate compact handoff. CoderFlow generates a cumulative handoff summary of the task conversation using a configured AI provider API key. The fresh agent session starts from this concise summary instead of the full instruction history, which keeps its context window small on long-running tasks.

A compact fork also stores complete backups under /task-output/fork-context/ in the fork: a readable transcript, the exact raw event stream, the original instructions, and the follow-up history. The agent is pointed at these files and can consult them when the handoff alone is not enough.

Compact handoff generation needs an API key for at least one supported provider. If generation is unavailable or fails, the fork is still created and automatically falls back to full task history; CoderFlow tells you when this happens.

On the forked task's page, a chip next to the Forked from link shows which context mode the fork used. For a compact fork, click the Compact handoff chip to read the generated handoff that the agent received.

Forks are useful when:

• The first approach is close, but you want to explore a different direction.
• A task failed after producing useful local changes.
• You want to keep the original result untouched while trying follow-up work.

A fork starts as a separate task that can be continued with a normal follow-up. It is not a replacement for resubmitting the same task to multiple agents.

Rewind a Task

Rewind lets you move the conversation context back to an earlier follow-up point. Use it when the agent took a wrong path and later follow-ups are making the task worse.

1. Open the task page.
2. In Task Details, click the follow-up count beside Follow-Ups (for example 1 follow-up). It opens Follow-Up History.
3. Choose Rewind to initial or Rewind to #N.
4. Optionally explain why you are rewinding.
5. If available, check Also rewind files to this point.
6. Submit a normal follow-up to continue from the rewind point.

Rewind points are based on the initial task instructions and each follow-up instruction. Rewinding to follow-up #2, for example, keeps the initial task and the first two follow-ups as the active conversation branch, then excludes later follow-ups from the replay context.

Conversation vs. File State

Every rewind prepares conversation context. File rewind is separate and appears only when CoderFlow has enough turn-patch metadata to restore files safely.

If you do not rewind files, the agent keeps the current filesystem. CoderFlow warns the agent when the current files may contain changes from after the rewind point, but you should still check the changed files before relying on old context.

If you do rewind files, CoderFlow tries to restore repository contents to the selected point and then refreshes the changed-files view.

Rewind requires the task container to be available and not actively running. If the container has stopped, start it before rewinding.

Resubmit a Task

Resubmit starts new task runs from the same task setup. It is best when you want a fresh attempt with the same environment, branches, and base instructions.

1. Open More actions.
2. Choose Resubmit Task.
3. Select one or more agents.
4. Edit the instructions if the next attempt should differ.
5. Attach any new files or screenshots.
6. Decide whether to add the new run as a variant.
7. Click Launch.

Resubmit preserves the original branch selections, IBM i build library list, environment variables, Jira link, source objective link, and task files. New attachments are added to the copied task files and replace files with matching names.

When the environment's IBM i build connection has library lists, the dialog's IBM i Build Library List section shows the list the new runs will use and lets you choose another. A list chosen for the original task is found again by name, so changes to its libraries since then apply; if that list has been deleted, the connection's default is used, and a task that used the default uses the current default. Forks carry the library list the same way.

You can launch more than one agent from the resubmit dialog. If you select multiple agents, CoderFlow creates a task group for the new runs. If you check Add as variant to existing group, CoderFlow adds the new tasks to the current group instead.

Resubmit is different from a follow-up:

• A follow-up continues the same task and container.
• A resubmit creates new task IDs and new containers.
• A fork creates one independent continuation from the current task state.

Switch the AI Provider or Account

When a task's AI account stops working, for example because its sign-in expired, you can move the task to another account without starting over.

Open More actions → Switch AI Provider or Account.... The same choice is offered when a follow-up fails because the task's account is no longer available.

The dialog shows the Current account and the connected OAuth accounts you can switch to. Each is marked Your account or Server account, with its plan usage; expired ones are marked Sign-in expired. When more than one provider is offered, choose the AI provider too. Then click Switch account (or Switch provider).

What changes:

• Same provider, another account: the next follow-up uses the new account. The conversation, workspace and agent session stay as they are.
• Another provider: the next follow-up starts a new agent session in the same container and replays the conversation to it. Earlier reasoning is not carried over, and the provider's default model is used.

When it is available:

• The task is completed, failed, interrupted or staged, and its container still exists.
• No automatic review loop or follow-up queue is active. Otherwise, pause them first.
• You have the change and execute permissions on the task, and another account is available.
• The task already runs on an OAuth account, even one whose sign-in expired or that was removed since. A task on an API-key account, or with no account recorded, needs a fork instead.
• Test, deploy, documentation-publish, interactive and Portal tasks don't offer it.

Some limits apply:

• Your personal accounts appear only on tasks you created. On someone else's task, fork it to use one.
• Judge and review tasks, and tasks that are one of several variants in a group, can switch accounts but not providers.

Save as Objective

Use Save as Objective when a task has useful instructions that should become reusable planning context.

1. Open More actions.
2. Choose Save as Objective.
3. Review the pre-filled name, environment, agents, and instructions.
4. Edit the instructions into objective-quality requirements.
5. Click Save Objective.

The new objective keeps the task's environment, branch selections, Jira link, and supported agent settings such as Claude effort level or Codex reasoning level. It does not automatically summarize the task result for you, so revise the instructions before saving if the task outcome changed what the next agent should do.

Snooze a Pin

When a task is pinned, the pin menu offers snooze choices in addition to Unpin. Snoozing hides the task from regular task listings until a time you choose, then returns it automatically, without unpinning it. You can still find it in the dedicated Snoozed view. Its container remains subject to the pinned 48-hour inactivity stop threshold and normal stopped-container removal rules; snoozing does not provide container protection. See Container Lifecycle.

1. Open the pin menu on the pinned task.
2. Under Snooze until, choose Later today, Tomorrow or Next week. Each shows the time the task returns, and choosing one snoozes it right away.
3. For any other time, choose Custom…, pick a quick preset or an exact date and time, then confirm.

While a task, or a child task it created, is queued or running, or has a follow-up queued or scheduled for later, the menu also offers It finishes. The task then stays snoozed until it has stopped running (completed, failed or interrupted) and returns on its own, and its badge reads Until done. For a grouped task, every variant must finish. A judge launched while it is snoozed this way joins the snooze, so the item waits for the judge too. The task also waits for every child task it created, with their own children and judges, whether or not they are pinned and even if they started after you snoozed it. When a finished child wakes the task to carry on, the task returns once that turn ends. A follow-up scheduled for later is a turn still to come: an orchestrator that set itself a wake-up, or scheduled a message for one of its children, stays snoozed until that turn has run. Removing the scheduled follow-up brings the task back, and so does a follow-up queue paused for your attention. A child task moved out of the task on the dashboard, or one you cannot open, is not waited for. If the work is still running, or a wake-up is still to come, a week later, the task returns anyway. A live interactive terminal session is not work the snooze waits for.

The snooze dialog offers the same choice as an Until done tab beside Duration and Date & time, so it is also there when you open the dialog directly: by pressing S on a tile, swiping left, or selecting the snooze badge. On a task already snoozed this way, the dialog opens on that tab. Mass snooze of selected items offers only return times.

While a task is snoozed, its pin button shows a clock instead of the filled pin, and selecting it opens the pin menu rather than unpinning. The menu also offers Unsnooze to bring the task back to Pinned immediately, and Custom… opens the dialog to pick a new return time. Every change shows an undo toast. Snoozing a grouped task snoozes all of its variants and their judge together, so they return as one item.

A snooze applies to your own Pinned list. Snoozing a task someone else created hides it from your lists only, and their pin and snooze stay as they are. Only the creator's own pin gives the container the 48-hour grace.

When the tile shows an agent's response, the pin menu also offers Mark as unread, which brings back the tile's new-response dot as a reminder, or Mark as read. Read state is kept per browser.

On a phone or other touch screen, you can also swipe a tile in any tab of the Tasks or Objectives view, or in their search results. Objectives swipe the same way as tasks. Swipe right to pin the item, or to unpin it if it is pinned. Swipe left on a pinned item to open the snooze dialog, or on a snoozed item to unsnooze it; an unpinned item has nothing to snooze. As you swipe, the action appears behind the tile; to cancel, slide the tile back before you let go. Each change shows an undo toast, and pins, unpins or unsnoozes you swipe in quick succession share one toast whose Undo reverts them all. In the Objectives view, pressing and holding a tile still before you move it drags it to reorganize, as before; a quick swipe does not. The Board view and the Pinned canvas keep their usual touch gestures.

For the full snooze workflow, presets, and the "Notify when snoozed tasks return" preference, see Snoozing a Pin and Notifications.

Schedule a Follow-up

To have the agent pick something up later, write the follow-up as usual and choose Schedule send (the clock button beside the attachment buttons, in the quick reply or the Conversation panel) instead of sending it. Pick a quick time (In 1 hour, This evening, Tomorrow morning, Tomorrow at noon or Next week) or any date and time up to 30 days ahead, in your local time, then choose Schedule. Ask CoderFlow can point at Schedule send, opening the reply box for you; it does not schedule a follow-up itself.

At that time CoderFlow sends the follow-up. If the agent is idle, it starts a new turn with it. If the agent is working, it waits for that turn to end, after any follow-ups already queued. CoderFlow keeps the time on the server, so you can close the page. If the task's container was stopped for inactivity, it is started again first. A scheduled follow-up survives a server restart, even for a task older than the task history the server loads at startup. If the server was down at its time, it is sent when the server is back.

Until then, the follow-up is listed under Scheduled below the reply box, with its time and who wrote it:

• Send now sends it right away, or queues it if the agent is working.
• Edit changes its text, attachments, model or time. Only the person who scheduled it can edit it.
• Remove cancels it.

Scheduling does not hold anything up. Follow-ups you send meanwhile go to the agent as usual. When its time comes, a scheduled follow-up joins the follow-up queue with a scheduled tag. A queue on hold after a failed or interrupted turn holds it too, until someone sends the queue on. While a follow-up is scheduled, the task's stopped container is not removed automatically. See Container Lifecycle.

Tasks can schedule follow-ups too, including a wake-up for themselves. A lead task asked to check back tomorrow at noon, or to retry a child later, uses follow_up_task with a delivery time; see Follow-up tasks. A wake-up a task scheduled is listed as From this task.

Activity Snapshots

When a task page opens, CoderFlow loads a small activity snapshot before replaying the full activity stream. This snapshot scans the tail of the task's debug stream and shows the latest agent response in the Latest Update area quickly.

The snapshot is not a separate artifact you manage. It is a fast first view while the full activity feed loads. If the task has no activity stream yet, the task page simply waits for the normal feed.

The same scan supplies Last Activity in the task's Details card, which shows when the agent was last active as both a relative time and a full timestamp. It keeps counting up while a task runs, so a long-running task shows how recently it did something rather than only when it started.

Task Output Files

Agents write their results to /task-output in the container. Two of those files are referenced often enough that the task page opens them directly instead of sending you to the file browser:

• /task-output/summary.md - Opens the task's Summary section, expanded.
• /task-output/commit-message.txt - Opens a Commit Message dialog showing the commit message the agent proposed, with Copy and Open raw file.

The links appear wherever the agent mentions these files in its activity feed. Any other file path still opens in the files panel as usual, and the match is on the exact path - a summary.md elsewhere in a repository is treated as an ordinary file.

Customize the Task Page

The task page layout is local to your browser. These controls help keep busy tasks readable:

• Drag a section by its handle to reorder the page.
• Collapse a section by clicking its header.
• Hide a section with the x control in the section header.
• Use Show to restore one hidden section, or Show All from the dropdown when multiple sections are hidden.
• Use Hide all sections to clear the page quickly.
• Use Reset Layout to restore the default order and clear hidden or collapsed section state.
• Use the expand control on a section to view it full screen.

Dragging is disabled while a section is expanded. Resetting the layout also clears saved hidden and collapsed state for the task-page sections.

Reorder Variant Tabs

When a task group is open, variant tabs can be reordered by dragging them. The order is saved to the task group, so it follows the group view instead of being only a local browser preference.

Use tab ordering to put the most important variants first before comparing, judging, or approving a winner.