Ask CoderFlow

Ask CoderFlow is the in-app assistant. Open it from the Ask button at the bottom of any page, or press Ctrl+J (Cmd+J on macOS). It answers questions about CoderFlow from this documentation, links the pages it used, and takes into account the screen you are on.

Ask CoderFlow needs a server-wide Claude API-key account. See API-backed features.

The conversation stays with you as you move between pages in the same browser tab, including the cards of any changes it proposed and your auto-apply choice. New conversation starts afresh. Closing the tab, signing out (or reaching the sign-in page after your session expires), or a day without using the conversation also ends it.

Ask checks access again immediately before it uses a lookup's answer, including "not found" answers. If access changes while a read is in progress, Ask reads the current information again or reports that it is unavailable, so it never answers from what you could see before. Turning Ask off or losing the license also withholds an answer still in progress, and so does changing to an edition without Ask actions (such as Essentials) for the lookups that edition does not include. Reading again never repeats a change.

Voice and network connection

Voice conversation and OpenAI dictation capture your opening words locally while connecting. Once the microphone is available, you can start speaking without waiting for the service connection. Your browser may first ask for microphone permission.

While listening, voice input uploads about 64 KB/s (0.5 Mbps), plus connection overhead. Leave extra upload capacity for other activity and for buffered audio to catch up. If audio backs up for too long, voice input stops and asks you to use a faster or more stable connection. Spoken replies also use download bandwidth.

Panel layout

Ask CoderFlow starts docked on wide screens, as a side panel on narrower screens, and full-screen on phones. A layout you already chose is kept.

Choose how the Ask CoderFlow panel sits on the screen with the layout button in its header, next to Maximize:

Layout	What it does
Floating window	A window in the bottom corner.
Side panel	Full height at the side of the screen, over the page.
Docked	Full height beside the page. The page makes room for it, so you can see both at once.

• Resize the panel by dragging its inner edge, or for the floating window its top edge or top corner. You can also focus an edge and use the arrow keys. A double-click on a side edge, or Home, resets it.
• Move the panel to the other side with Move to the left side (or right side) in the same menu, or by dragging the Ask button across.
• Maximize works in every layout.
• Remembered: your layout, side and sizes are kept by this browser.
• Esc: it closes the floating window. A side or docked panel stays open while you work on the page; Esc closes it when you are in it.
• Small screens: a docked panel narrows to fit beside the page. If the window is too narrow even for that, it shows over the page until there is room. On phones Ask CoderFlow always fills the screen.

Docked suits working with Ask CoderFlow as you go. When it opens a page for you, the panel stays open beside the new page.

Settings

Administrators configure the assistant in Settings → Ask CoderFlow:

Setting	Default	What it does
Enable Ask CoderFlow	On	Shows the assistant to every user. Turning it off hides it for everyone.
Model	Sonnet	The Claude model that answers. For a custom AI endpoint, type that endpoint's model ID.
Allow Actions	Off	Allows changes with the user's permissions and confirmation policy. Read-only lookups in Full edition remain available with this off. See Actions.
Auto-Apply Limit	Reversible changes	The most a user can let one conversation apply without confirming each change. See Auto-apply.
Enable Telemetry	Off	Sends completed questions and answers, with answer ratings, to Profound Logic to measure and improve answer quality. Nothing else to set up. See Usage telemetry.

Usage telemetry

When Enable Telemetry is on, CoderFlow captures each completed Ask CoderFlow answer: the question, the answer, and metadata such as the page, model, tools used, timing and token counts. Every 30 minutes (the Push Interval) it sends what it has captured, with users' thumbs-up and thumbs-down ratings and comments, to Profound Logic at coderflow.ai. Batches identify your server by a random instance ID and its CoderFlow version, not by name. Nothing is captured while telemetry is off. Ratings are always saved on your server, but only those given while telemetry is on are sent: turning telemetry on never sends earlier questions, answers or ratings, and turning it off or changing Send To keeps anything not yet sent on your server. After upgrading from an earlier version, save these settings once to start sharing new material.

Everyone using Ask sees whether telemetry is on, above the question box in the Ask panel: Telemetry on, Telemetry off or Telemetry status unavailable. Hover over it, focus it or tap it for what is shared (questions, full answers, ratings and comments) and where it goes. Follow-up questions in a conversation, and ratings of their answers, are shared only while the whole conversation took place with telemetry on and the same Send To; older conversations are never shared.

The Status row shows how many records are waiting and when the last batch was sent. Test connection sends an empty test batch.

To keep telemetry in-house instead, set Send To to Custom processing server and enter your receiver's Processing Server URL and Signing Secret. Batches are then signed and sent only to that server. Switching back to Profound Logic (coderflow.ai) removes the saved URL and secret.

Reading users, teams and access

Ask can read the access information you can read in CoderFlow. For example:

• “Who belongs to the Platform team?”
• “Which permissions does the Approver role grant?”
• “Show Alice's bindings on Production.”
• “Why can Alice approve tasks in Production?”

It can look up team members and management flags, roles and their permission sets, the permission catalog, and bindings by user, team or resource. Server administrators can also read the safe user profile, including membership and access summaries, direct versus inherited administrator access, MFA enrollment status and connected-account metadata. Passwords, MFA secrets, API keys, sessions and tokens are never returned.

Visibility follows the same routes as the pages. User profiles and user lists require full Server Administrator access; a delegated users:view permission does not bypass that restriction. A team manager can inspect the teams they manage, while the normal team listing still shows their memberships. Member IDs are shown without resolving otherwise-inaccessible user profiles. Binding reads include your own access, your teams' access, and resources you can manage. Roles and permission definitions are readable by signed-in users.

An access explanation uses the current permission resolver and identifies the visible direct and team grants. It is an explanation, not a simulation of future changes. For yourself or a server administrator, it can establish a permission grant or denial. If you can see only part of someone else's access, Ask reports visible grants and leaves the rest unknown; no visible grant does not mean the user is denied. Partial explanations in draft or disabled environments also remain unknown. A permission grant does not establish every operation-specific check, such as task ownership or an edition requirement.

Long lists are read in pages. Ask must follow subsequent pages before claiming a complete list, and treats explicitly truncated text as incomplete. These are read-only lookups and work with Allow Actions off. Ask does not change users, teams, roles or access: see Changing users, teams, roles and access.

Changing users, teams, roles and access

Ask does not change users, teams, roles or access. Creating, editing or deleting a user, resetting MFA, adding or removing a team member, creating, renaming or deleting a team, creating, editing or deleting a custom role, and granting, changing or revoking access are administrator changes you make on People & Access. When you ask for one, Ask explains how and opens the Users, Teams, Roles or Access tab where you make it, if you can open that tab (see Opening pages). Opening the page changes nothing: you make the change there, with the page's own controls and checks.

Earlier versions of Ask could make some of these changes with a card. Such a card in your Recent actions is now an Earlier Ask change (now made in the CoderFlow UI) entry: it says only that Ask no longer makes these changes and where to make them, and it cannot be confirmed (see Recent actions and restoring cards).

Opening pages

Ask CoderFlow can take you to a page. For example: "Open the login fix task", "Show me my running tasks", "Take me to the Production environment's variables" or "Where do I set the Ask CoderFlow model?". It can open:

• a task, including a file in its container at a given line
• a task group, or one task in it, or a judge's verdict
• an objective
• the dashboard, for an environment or one of its sections (Pinned, Snoozed, Running, Terminal, All)
• an environment in Environment Management, on a given tab
• a section of Server Settings or Server Administration (administrators only)
• the Users, Teams, Roles or Access tab of People & Access, when that tab is shown to you
• My Work
• Requests: an IT request queue you can read, or one request in it

The page opens when the answer finishes, and the conversation continues there. A line under the answer says which page it opened, with a link. When the page you are on can show the destination itself, such as another task in the same group or another settings section, it does so without reloading.

• Ask CoderFlow opens only pages you could open yourself. It never opens other websites.
• Opening a page changes nothing in CoderFlow, so it needs no confirmation and works without Allow Actions. In Full edition, Ask CoderFlow can find tasks by name using its read-only tools whether Allow Actions is on or off. When those tools are unavailable, it can use the task you are looking at or an ID you provide.
• Edits you have not saved on the page you leave are handled as when you click a link: pages that warn about unsaved changes still warn.
• If you stop an answer before it finishes, the page does not open; use the link instead.
• In a voice conversation, a page change would end the conversation. Ask CoderFlow switches within the page you are on when it can, and otherwise gives you the link.

Opening an application in QA mode

Ask can list an environment's QA Mode destinations and give you a link that opens one in QA mode. Try "Which QA destinations can I open in Production?" or "Open the storefront in QA mode".

• The list shows each destination's name, description and application type: the same enabled destinations as the QA items in the dashboard's Quick Actions menu. You need the Access QA proxy mode permission (qa:access) for that environment. An empty list means QA is turned off or has no usable destination; destinations that use URL templates such as {{origin}} also need the Site URL to be set.
• The answer never shows destination URLs, proxy addresses or the application's stored credentials. Text an administrator wrote, such as a description, is shown with known secret values and credentials in URLs removed; a name or description that still contains percent-encoded characters (such as %20), which could hide a credential, is not shown: the destination appears as "QA destination N" without a description. A destination whose address itself contains a secret value or a credential (for example a token= parameter) is listed, but Ask does not offer a link to it; open it from the Quick Actions menu.
• The link appears under the answer as Open name in QA mode (new tab). Nothing opens until you click it. The link itself holds no address: on the click, CoderFlow checks again that you still have QA access and that the destination is still configured and enabled, and opens it in a new tab, the same way the Quick Actions menu does. If anything changed, nothing opens, and every QA link on the page that is no longer available is replaced by the line This QA mode link is no longer available to you. A link that arrives after that, for example from an answer that was already on its way, is shown only after CoderFlow checks it again.
• Ask reports only that it opened the application in QA mode. It cannot see, test or operate the application, and it never says that something was tested or an issue reproduced.
• Opening QA mode changes nothing in CoderFlow, so it needs no confirmation and works without Allow Actions. Listing destinations uses the read-only tools, so it needs Full edition. One answer offers at most three links. Links are not kept when the conversation continues on another page; ask again there.

Capturing QA evidence is intentionally not available in Ask; use the QA feedback widget on the opened page instead. There you capture screenshots, selected page elements and screen data, and review them before creating an objective or launching tasks from them. If you ask for evidence to be captured, Ask explains this and offers the link. It can still create a text-only task or objective with the normal action tools and confirmation.

Reading your Portal and finding things there

Ask CoderFlow can read your own Portal (CoderFlow for Business) and show you where to do something there. Try "Which reports do I have in Finance?", "When does my morning stock question run next?" or "How do I share my stock report?".

It reads, for you only:

• the workspaces (environments) you can open in Portal;
• a workspace's applications, with which ones are your favorites;
• its saved reports: yours and those shared with you, with their name, who shared them, which version is active or waiting in preview, whether yours are shared, and whether a report is being generated. Never a report's content, its queries or their results: open the report in Portal for those;
• your private Portal conversations: names and times, never the messages;
• your scheduled questions and their runs, with each answer's name while you can still open it.

It uses the same access as Portal itself: Portal and the environment's Portal switch must be on, and you need Portal access; reports and conversations also need Portal data access, applications Portal applications, and scheduled questions Use automations there. A report someone shared appears only while report sharing is on, as the version they shared. Ask never shows another person's private reports, conversations or schedules, even to IT. These reads need Full edition and work without Allow Actions.

Ask does not change anything in Portal. When you want to, it gives you a link under its answer, Open in Portal (new tab): followed by what it points at. Nothing opens until you click it. Then CoderFlow checks again that you still have access and that the item and its control are still there, opens Portal in a new tab at that exact place, and highlights the control once. You use it yourself: Ask never clicks it, and the control's own dialog or confirmation still appears. The conversation stays where it was. If anything changed, for example the report was deleted or unshared, or your access was removed, nothing opens and the line reads This Portal link is no longer available to you. Nothing was opened.

You ask about	Portal opens and highlights
A workspace or an application	The workspace; the application in Applications (you open it yourself)
Favoriting an application	Its star
A report; creating one	The report; New report
Revising a report, using a new version, stopping or retrying a run, starting over	Use this version, Stop or Discard preview, Try again or Start new conversation in the report conversation, or Edit report, which opens it
Renaming, deleting or pinning a report to the IT dashboard	Rename report, Delete, Pin to IT dashboard or Unpin from IT dashboard; for a draft, Delete draft or its rename button in Saved Reports
Pinning a report or an application to Home	The report's Pin to button, named for your Home dashboard (Pin to My Dashboard, or Unpin from… when pinned); for an application, its pin in Applications
A question Portal's assistant is waiting for you to answer in one of your conversations	The conversation, with the question's Send (choose your answer above it). Offered only while the question still waits; Ask never sees the question or answers it for you
Sharing a report or stopping sharing	Share, or Shared, whose dialog has Stop sharing
Asking IT to change a report, a conversation or an application	Request a change, Request for IT, or the application, whose Assistant has Request for IT
A conversation; renaming or deleting it; a new question	The conversation; its rename button; Delete; New question
Scheduled questions	Automations, New scheduled question, a question's form, On, Run now or Delete…
Your requests to IT	My Requests, New request, a request, Send reply, Accept, Reopen… or Withdraw request…

One answer offers at most three Portal links, and they are not kept when the conversation continues on another page. Arranging dashboards and their tiles (other than Pin to Home), report folders and moving reports, report icons and colors, sample reports, personal IBM i logins and Portal secrets, and Portal setup are used rarely: Ask explains them from the documentation instead, such as the Portal guide's Home and dashboards, Reports and Personal settings pages.

Reading settings and diagnostics

Ask can read non-secret general settings, Ask policy, model choices, resource limits, Docker storage and update policy. It can also report whether AI providers, Git providers, email, Slack, Teams, Jira, SSO and the external MCP server are configured or enabled, with safe metadata such as provider names and hosts.

Try “What resource limits apply to task containers?”, “Is Slack configured?” or “Which skills have updates available?” The same Settings and Skills permissions as the corresponding page apply. Catalog and installed-skill lists can use shared scope or a named environment. Update checks inspect installed sources using the same cached checks as the Skills page, including npm view with the server's npm configuration for skills installed from npm: an administrator installed those packages, Ask did not choose them. They do not install or update anything.

Server administrators can also ask for server health, system metrics, containers, usage statistics and a bounded server-log tail. Usage reports retain any history-coverage limitations. An unavailable result is not an empty result or proof that everything is healthy.

These reads run immediately with Allow Actions off, when the normal Ask license and edition requirements are met. They exclude credential values, masked credential fragments, signed URL paths, container labels and update/restart commands. Logs redact credential patterns and omit structured context and warning/error/exception text; use Server Administration when those diagnostic details are needed. Lists show up to 25 items by default, at most 100 per request; log messages are limited to 8,000 characters by default, at most 24,000.

Ask does not change settings: it reads them, explains what to change and, for administrators, opens the Server Settings section where you make the change (see Opening pages). Integration setup and tests, and server prune, update and restart, also stay in their existing interfaces. Ask does not install or update skills: it offers a button that opens the Skills page's import dialog, or the skill to update (see Installing and updating skills). Task agents using delegated task tokens cannot call these server-wide read tools.

License status

Server administrators can also ask “What license is installed, which modules does it include, and when does it expire?” Ask reads the same administrator-only status as Server Administration → License: license type, edition, modules, expiry and restart state. It omits the key, signed tokens, machine identifier and commercial terms. The read needs Full edition and a valid license, and works with Allow Actions off. If your access changes or a replacement license is still being installed, Ask reports the status as unavailable; ask again later or check the panel.

Installing or replacing a license is intentionally not available in Ask, because it is a rare administrator action involving a secret; use Server Administration → License instead. Ask explains this and opens the panel. Enter the license there, never in the conversation, then ask for the status again. Opening the panel does not install a license, and Ask never resumes or repeats an installation. Ask is unavailable while the server is in limited (unlicensed) mode; use the license recovery page instead. See License administration.

Reading documentation publication

In Full edition, Ask can inspect Docs Hosting without Allow Actions or confirmation. Try:

• “Which repositories in Production host documentation, and which commit is live?”
• “Which approved and pushed tasks have documentation candidates in Production?”
• “Show the output of this documentation publish task.”

The environment read uses your environment-detail permission. Candidates and publish-task output use the same task visibility and content rules as the task page. Candidate eligibility follows the task page's approved-commit and publish-branch checks, so a missing commit or a mismatched publish branch stays blocked. It also reports whether you have deployment execution permission; it does not authorize or start a publish. Inaccessible or deleted linked tasks are omitted. A repository without Docs Hosting is shown explicitly. Candidate lists reveal no distinction between a missing environment and one where you cannot view any tasks.

Ask distinguishes the published site, the last visible attempt and a running publish task. A completed container alone is not proof that the site was promoted. Results include an observation time. If access or state changes during the read, Ask refreshes the observation or reports it unavailable.

Lists return up to 10 entries by default, at most 25 per page. Publish output is a redacted tail of log.txt, up to 6,000 characters by default and 12,000 on request; omission markers mean it is incomplete. Known environment secrets, including deploy-only credentials, and task-owner credentials are removed from labels and output, along with URL credentials. If either credential source cannot be read, Ask reports the read unavailable. An unavailable log does not mean the task produced no output. These tools are unavailable to delegated task tokens. Publishing, republishing and retrying are intentionally not available in Ask; use the Publish Docs controls instead.

Changing the view within a page

Ask can search and filter the dashboard, switch its view or section, show a task's changes, activity, logs or output summary, open Conversation or Files, open a changed file's diff, and expand the latest update. It can also scroll to Settings or Environment sections and set the Server Administration log filters.

For example: “Search for login and show completed tasks”, “Open this task and show its output summary”, or “Show the diff for src/login.js”. Name a specific file or section when more than one could match.

These view changes run when the answer finishes. Each command shows its outcome under the answer, and the conversation remembers it when you move between pages. Stopping an answer prevents its pending view changes. If a view is unavailable, Ask reports that instead. During voice conversations, commands can change the current page; destinations requiring another page remain links.

Ask can also open and close Canvas: “Take me to Canvas” or “Close Canvas.” Opening it selects the dashboard's Pinned section and clears search. It preserves Objectives view, or switches from Board to Tasks. Canvas requires pinned items and a window wider than 720 pixels. Ask reports when it cannot open it. Canvas is separate from the swimlane Board view.

View commands do not require Allow Actions and never save, submit, approve, delete or deploy anything.

Showing where a control is

Ask CoderFlow can point at a control when you ask where it is. For example: "Where do I set the auto-apply limit?" or "How do I search my tasks?". It opens the page, section or tab first if needed and scrolls to the control. It then outlines the control, dims the rest of the page and adds a short tip beside it.

• It only points. It never clicks, changes or saves anything, so it does not need Allow Actions. Clicks pass through the dimmed page, so you can use the control at once.
• Dismissing it: press Esc, click or type on the page, or scroll it. It also goes away after a few seconds.
• A wide panel: if the Ask panel leaves no room beside it for the tip, the tip appears in the line under the answer instead.
• Finding the control: Ask finds controls by their on-screen label. A control inside a closed menu, such as Auto-pin new tasks in the task prompt's Task options, is shown by outlining the menu's button. The line under the answer repeats only what Ask looked for, such as "Showing where “Auto-pin new tasks” is: its menu.", never other text from the page. If several controls match, or none, it says so; name the section or dialog to narrow it down.
• When it cannot point: Ask points only at controls you may use. On a task page, when it cannot point at a control such as Discard changes, Send as Follow-up... or a changed file's Download, it says why in one of a few fixed reasons, never in text from the page: you do not have permission to change the task; only the task's owner can do that on a private task; it is no longer available (such as a file whose changes were discarded); or it is not available in its current state (such as while the task's container is stopped). Otherwise it says it cannot point at it right now.
• Task content: Ask never points at links or controls inside task output, comments or files.
• On a phone: the Ask panel closes so you can see the control. In a voice conversation it stays open, and Ask tells you to close it.

Ask shows you where

Some everyday task features take one click once you know where they are. For these, Ask CoderFlow shows you the control instead of doing it for you or describing the menus. It opens the task if you are not on it, then points at:

You ask about	Ask points at
Adding a comment or mentioning someone	The Comments box
Editing or deleting your own comment	Edit or Delete on that comment (name it, such as "my last comment", when you have several)
Sharing a task, sharing it view only or making it private	More, where Sharing... is
Setting or clearing a custom field	The field in Task Details
Rewinding to a turn	Rewind to #N for that turn, in the Follow-Up History dialog it opens
Resubmitting or deleting a task	More, where Resubmit Task... and Delete Task... are
Starting a stopped task container	Start
Answering the agent's question, triage or ranking	The question itself, scrolled into view: its options and Send. Ask never picks an answer for you
Scheduling a reply, attaching files, choosing the model for the next reply, replying to all variants, or connecting your computer	Schedule send, Attach files, the model chip, Reply to all or Connect my computer in the reply box, which Ask opens without typing anything
Discarding one file's changes	That file's Discard changes in Changed Files (shown while the task's container runs)
Stopping or continuing an auto-review, cancelling a review you scheduled, or sending a judge's feedback	Stop or Continue, Cancel request, a variant's Send as Follow-up..., or Review all follow-ups… when the judges disagree, in the AI Judging dialog, which Ask opens on the right tab
Your computer on a task (CoderFlow Link; the task's owner)	Pause, Resume, Disconnect, More options or screen control's Continue in the Your computer row; Undo all or one change's Undo in Changes on your computer; a command's Output or Stop in Agent Activity
Asking about the task in a side chat, opening VS Code or a terminal, opening the running app, or opening a pull request for a pushed branch	Side chat; VS Code or Terminal (while the container runs); Launch URLs or Start Server & Launch in the Testing menu; Create Pull Request
Snoozing a task until it finishes	The pin button (Pin options (snooze or unpin)): open it and choose Snooze until → It finishes

When the control repeats (several changed files, changes on your computer, commands or variants), Ask points at the one you named, and says it cannot tell them apart rather than guessing.

On the Environments page, Ask points at these instead of doing them:

You ask about	Ask points at
Testing an automation's SCM poll	Test Poll in the automation's editor, or that automation's Edit button while the editor is closed
Checking a connection's special authorities, RAS or Profound UI	Test connection in the connection's dialog, which Ask opens; it checks each service the connection uses
Checking a connection's library list	Manage lists… at Library Lists in the connection's dialog; a list is checked when you change it
Setting up Portal launch trust	Set up launch trust… in the connection's dialog, then Review setup or Cancel setup in the Launch trust dialog
Committing and pushing setup repository changes	Commit & Push… or Push to Git on the Environments page (the publish button, or the Actions menu); for shared skill files, Commit & Push on the Skills page

For an automation or a connection, Ask points only into that automation's editor or that connection's dialog, never another one that happens to be open.

You then use the control yourself. Ask never clicks it, saves anything or confirms it for you, so it does not need Allow Actions; the control's usual confirmation still appears, and you need the same permissions as without Ask. For a rewind, Ask opens Follow-Up History only to show the turn's Rewind button: the dialog changes nothing, and Rewind asks you to confirm first.

Before pointing, the page checks again that you can still open the task and use the control, even if it has been open for a while. If the task changed (another variant was opened, say, or it was made private meanwhile), or you no longer have access, the line under the answer says what could not be shown rather than pointing somewhere else. Pointing only shows where a control is: the control itself still checks your permissions when you use it.

The dashboard, Build Images, server logs and My Work

Ask points at these too, opening the page first when you are elsewhere:

You ask about	Ask points at
A launch option Ask cannot set when it starts a task: sharing, a custom field, auto-review, importing from Jira, the IBM i build library list, connecting your computer, launching in terminals	Share task, the field, or the option in the launcher's Task options menu (Auto-review tasks..., Import from Jira...), Quick Actions (IBM i Build Library List..., Connect my computer...) or the launch menu (Launch in Terminal(s)); Ask can fill in the form first
Running a test task with no agent	Quick Actions, where Run Tests... is
Sorting the board, its list or tile layout, whose work it shows, or collapsing objectives	Sort tasks, the layout button, User filter, Collapse all objectives or Expand all objectives
Moving a task into or out of an objective	That task's Move button on Canvas, which Ask opens; you choose where it goes
The model or effort for your next reply, in the dashboard's conversation drawer	The drawer's model control (Next follow-up), when the drawer is open on that task; otherwise the task page's
Building the base image or several environment images	Actions → Build Images... on the Environments page (the base image needs the server:build permission), also when Ask could not build an environment because its base image is missing
Where the server logs are (Server Admins)	The Logs tab in Server Administration, which Ask opens
Turning usage telemetry on or off (Server Admins)	Enable Telemetry in Settings → Ask CoderFlow, which Ask opens; you switch it and press Save (see Usage telemetry)
Logging, editing or removing time, or downloading your time or activity	Log time, one entry's Edit or Remove (say which entry, by its date, hours or description), Download time CSV or Download activity CSV on My Work

An option the page does not show you (Jira not set up, CoderFlow Link off, or your edition or permissions do not include it) is not pointed at: Ask says it is not available. Ask names the Environments tabs as the page does (Repos, Server, Instructions, Secrets and so on). Before pointing, the page checks again that you can still create tasks in the launcher's environment, open and change the task, build images, that you are still a Server Admin (the logs and Settings), or that My Work still shows your own entries.

IBM i sync and deployments

Ask also points to the IBM i controls that send a task's work to IBM i or deploy a profile, after reading where things stand (see Reading IBM i sync and deployments):

You ask about	Ask points at
Syncing a task's changes to an IBM i library, or deploying its Profound UI htdocs files	The task's Sync to IBM i control, labelled Deploy htdocs or Sync to IBM i & Deploy htdocs when that is what it does (in More task actions when the action bar is narrow)
What an IBM i pipeline deployment did	Deployment details… on the deployment task
Deploying an IBM i deployment profile	Quick Actions on the dashboard for that environment, where Deploy... is; once you have chosen the profile and its review is open, its Deploy, Edit or Add targets
An IBM i profile's deployment history or hold	Deployment History on the environment's Deploy tab, with that profile shown

Ask never opens the Sync dialog or the deployment review for you: the Sync dialog is where you enter an IBM i user and password when it asks, and the review prepares a proposal from Git. Before pointing, the page checks again that you can still use the control: that you can run the task (for Sync), run deployments in the environment (for Deploy...) or view them (for the history). For Sync it also reads the task's IBM i connections again, so the label matches what the control does now.

IT Requests

On the Requests page, Ask CoderFlow points at the control for everyday request work instead of doing it. It opens the request first if you are not on it:

You ask about	Ask points at
Replying to the requester	The reply box (Reply to requester)
Changing the status, marking it Ready to try or Resolved	Change status… (the statuses are in the dialog it opens)
Reopening a closed request	Reopen…
Assigning it, or taking it yourself	Assignee, or Assign to me
Changing the priority	Priority
Adding an internal note	The Internal notes tab
Linking a task or Objective, or unlinking one	Link existing…, or that item's Unlink…
Starting a task for the request	Launch task…
Preparing, reviewing, publishing or discarding an AI draft	Prepare draft, or that draft's Review… or Discard
Opening a file someone attached	The file's link in the conversation
Creating a request	New request (in one environment's queue)

Ask never opens the Internal notes or History tab for you, because viewing a tab marks its updates as read; it points at the tab instead. Before pointing, the page reads the request again, so if another IT user changed it meanwhile (resolved it, say) Ask points at what is there now, such as Reopen…. If another IT user added a draft or linked work in the meantime, Ask points at the item it named or says it is not shown, never at a different one. If you can no longer read the request, nothing is shown.

Replies and status changes are shared with the requester; internal notes and priority are not, and internal notes are never emailed to the requester. Email goes out only when the server's email is set up and the recipient's preferences allow it.

Features that are rarely used are explained briefly from the documentation, without an offer to do them (the list is under Actions). For example, you stop or remove your own standalone interactive container with coder containers clean, and server maintenance (pruning, updates, restart) is in Server Administration → Health.

Ask walks you through it

When something takes several clicks, ask Ask CoderFlow to walk you through it, for example "Walk me through letting Ask make changes without asking me each time" or "Step by step, how do I stop new tasks being pinned?". Ask lists the steps in its answer, opens the first step's page when the answer finishes, and shows a step bar at the edge of the page:

• The bar says Step N of M and what to do, in Ask's words.
• Pointing: each step's control is outlined as in Showing where a control is, with the same checks before it is shown.
• You click it yourself. Using the control moves the walkthrough to the next step. When the control is inside a closed menu, Ask outlines the menu's button first; once you open the menu, it outlines the item.
• Ask never clicks. After opening the first step's page, Ask never clicks, types, submits or opens a page for you. Every change is your own click, with the control's usual confirmation and your own permissions, so a walkthrough does not need Allow Actions.

Button	What it does
Next (Finish on the last step)	Moves on without using the control
Previous	Points at the step before again. It does not undo anything you changed
Show again	Points at the current step again, for example after the outline went away
Go there	Shown when the step is on another page. Opens that page only when you click it
Stop	Ends the walkthrough

When a step cannot be shown, the bar says why in the same fixed words as a single pointer, and offers Ask about this, Skip and Stop. Ask about this puts "Step N of the walkthrough couldn't be shown." in the Ask box; it is sent only if you send it.

How long it lasts: the walkthrough continues on the next page, after a reload and after Back, in this browser tab. It ends when you press Stop or Finish, use the last step's control, start a new conversation, sign out or sign in as someone else, when Ask starts another walkthrough, or after 30 minutes without moving to another step. It also ends, showing nothing more, when you can no longer open a task, request or environment it points at. A walkthrough starts only when its answer finishes; if you stop the answer, it does not start. The conversation records each step's outcome and where you stopped, so you can ask a follow-up question.

On a phone, the Ask panel closes so you can see the control, and the bar stays on the page.

What it covers: two to eight steps, on at most three pages. Ask doesn't start a walkthrough for a rarely used feature (it explains it from the docs), or for steps inside an objective's dialog or a saved connection's dialog (an environment's Connections tab), where it points at one control at a time.

Reading IBM i sync and deployments

Ask can read, without changing anything:

• A task's IBM i sync and Profound UI deploy state, as its task page shows it: which IBM i connection syncs and which deploys htdocs files, whether the Sync dialog will ask for an IBM i user and password, the changed files the dialog offers (which can be synced as source members, which Profound UI JSON files sync as display files, and any two files that would land in the same member), how many files are waiting to be synced to the last library, the last successful sync or deploy and the recent rounds with their results, and whether you can use the task's Sync control now (and why not). You need to be able to view the task. If the task's container does not answer within a few seconds, or a file it should read cannot be read, what Ask would have counted from it (eligible and waiting files, Profound UI display files) is reported as unknown, not as zero. While the container is stopped, changed JSON files that may be Profound UI display files cannot be checked, so the eligible count is unknown too.
• One IBM i pipeline deployment (a run of an IBM i profile, a rollback or a hold clearance), as its Deployment details… dialog shows it, with each effect separate: the staging build on the build system (or a simulated one), the Git updates (the build tag, the deployment branch, a hold), and the destination install. You need to be able to view the deployment task.
• An IBM i profile's pipeline history and status, as the environment's Deploy tab shows them: each deployment, rollback and hold clearance with its outcome, user and commit, whether the pipeline is blocked or on hold, and its upstream profile's state. You need deployments:view in the environment. Ask leaves out only the task ID of a deployment that is in the loaded task list but that you cannot see in it; older deployments outside the loaded list keep their task IDs, as on the Deploy tab's history.

The destination install of an IBM i pipeline deployment is currently done by a development installer that only records what it would do: Ask reports it as simulated and never as a change on the destination IBM i. The staging build and the Git updates are real.

These reads never start, reserve or retry a sync or a deployment, and they return no logs, host names, credentials or IBM i messages; open the task or the Deploy tab for those. To sync or deploy, Ask points to the control. Importing IBM i sources, generating build rules, deployment recovery and holds, and installing CoderFlow on IBM i are rarely used, so Ask explains them from the documentation instead.

Reading IT Requests

In Full edition, Ask CoderFlow can read IT requests as the Requests page shows them to you: "What's new in my queue?", "Summarize REQ-000042", "What did the requester say last?". With IT queue access it reads the queue (filters, unread state, priority and assignee), a request's details and status, its shared conversation, its internal notes, the tasks and Objectives linked to it, any launch still pending and its AI drafts. As a requester, it reads only your own requests and their shared conversation, as the Portal shows them.

• The conversation the requester sees and the internal notes are read as separate, labelled streams, so Ask can tell you which is which.
• Linked work is shown only as far as your own task permissions allow: a task you can't open is mentioned without its name. Drafts built from work you can't see show no text.
• A delivery link to a Portal report or application is shown only while you can open that item yourself.
• People are named as on the page; email addresses are never read. Files are read by name and size only, never their contents.
• Reading never changes a request or marks anything read. To act on it, Ask shows you where (see IT Requests).

Filling in a form for you to review

Ask can fill in the dashboard's new-task form, or a task's follow-up box, and leave it for you to check. For example: “Set up a task in coderflow-dev to add retries to the webhook listener” or “Draft a follow-up asking it to add tests”. On the dashboard it can choose the environment, template and agent, and fill in the task name and instructions. It can also open another task first: “Draft a follow-up on the login fix task asking for tests”.

• Ask never starts the task or sends the follow-up. Review the form, change anything you like, then press Launch task or Submit follow-up yourself. The line under the answer says what it filled in.
• It chooses only what the form offers you: environments you can start tasks in, that environment's templates, and agents that are set up. If something you asked for is not available, the line under the answer says so and the form is left as it was.
• If the box already holds text you wrote, Ask asks above it first. Replace puts in its text; Keep mine, Esc or typing in the box keeps yours. Your text is also kept if you switch tasks or change the form before answering, or leave the question for three minutes. Ask leaves the box alone while you are dictating into it.
• If Ask needs another environment or template while the form shows your draft, it asks before switching. Your draft stays saved with its environment and template; switch back to see it again. If you start typing or dictating while Ask is still switching, it stops and leaves the rest to you.
• The text comes from your request. Ask does not copy instructions from task output, files, comments or web pages unless you ask it to use that text. It fills in text only, never images or hidden characters.
• Filling in a form changes nothing in CoderFlow, so it works without Allow Actions. With Allow Actions on, ask Ask to start the task or send the follow-up when you don't need to review it first; it shows a confirmation card.
• In a voice conversation, Ask fills in forms on the page you are on. A form on another page stays a link.

Reading task details

In Full edition, Ask can read task comments and mentions, changed files and individual diffs, queued follow-ups and rewind points, app server status and logs, and named test definitions with the latest retained run result. These lookups run immediately with your permissions, including when Allow Actions is off. For example: “Show the comments on this task”, “Which files changed in this repository?”, or “What is waiting in the follow-up queue?”

App server status and logs require the same task execution permission as their task-page panels. Other task reads require task-view access. A lookup never edits comments, changes the queue, rewinds, controls an app server or runs a test. Resuming the queue, editing or removing a queued follow-up, app-server controls and named test runs are separate, confirmed actions; see Controlling a task's runtime, Editing or removing a queued follow-up and Building images and running named tests.

Lists are paged and text is bounded and redacted. Ask distinguishes an empty result from unavailable information. Binary files and large patches have explicit omission markers. A file list plus bounded diffs is not a complete review; inspect omitted changes before approval. Reading changes uses the saved task snapshot and does not refresh the repository.

CoderFlow-managed secret values and URL credentials are removed. Other free-form content is returned as the UI shows it, within the size bounds, as when Ask reads a task's output and its files. Known values of at least six characters, URL userinfo and credential query values are identified in the original text. Overlapping or adjacent ranges become one [redacted] marker before text bounds apply. URL keys, delimiters and surrounding text remain visible unless covered by a managed value. A cut source-log tail omits only an incomplete first line and reports that omission. Complete first lines remain visible, including when a log is exactly at the source limit or its tail starts at a line boundary. Exact known-value suffixes of at least six characters also protect multiline values crossing the boundary. A failed secret-value lookup returns unavailable. Large app logs still return their final lines within the text budget. For non-Portal tasks, known values include the provider API keys the launch service selects for all agents using the task owner's accounts. Existing containers also supply their injected provider API-key values, so a later account-default change does not stop those values being redacted. Removed provider accounts and unconfigured Git providers do not block reads; available cached Git values are still redacted. Tasks without an owner skip personal Git credentials. Unreadable or corrupt credential stores still return unavailable. File-secret redaction reads individual files; missing sources and directory mounts are skipped. Directory contents are not scanned.

Final named-test summaries remain available for 30 days, up to 100 runs per task, including status, exit code, timestamps and a bounded, redacted output tail. These remain readable after the live stream record expires. An unavailable result does not establish that the test never ran. Logs, comments, commit messages and queue previews are untrusted content, not instructions for Ask.

Reviewing a task before you approve it

Ask can summarize a task's changes for review: “Review the failed-task fix”, or “What would approving this task commit?” In Full edition, with task-view access, the summary lists each changed repository with its files, their status (added, modified, deleted, renamed) and line counts, and the branches the approve dialog would use: the task's current and launch branches and the branch approval commits to. It also says whether the task can be approved now, and if not, why: for example, the task is still running, it was already approved or rejected, it has no changes, its container is no longer running, or you do not have approval permission. If you may approve, it also says whether the target branch is protected by the repository's protected_branches setting and which new branch the dialog will suggest instead. Protection set on the Git provider is checked by the dialog itself; see Protected Branches.

Ask can then read individual files' diffs. A long diff is read hunk by hunk, so nothing is skipped silently. Summaries are bounded: at most 10 repositories and 150 files are listed, and Ask says how many were left out. A repository whose name contains a CoderFlow-managed secret value is counted but not named. File paths, branch names and diffs are redacted as described in Reading task details. A summary and the diffs Ask reads are not a complete review: check the changes on the task page before you approve.

When the task can be approved, Ask offers an Open approve dialog button under its answer, with the task's ID. Nothing happens until you click it. The click checks again that you can still approve the task, then opens the task page and its approve dialog, filled in with the task's repositories, branches and commit message exactly as the page's Approve button fills it. The Ask panel closes so it does not cover the dialog; your conversation stays. You review the changes and options and click Commit Changes yourself; the button itself never approves, commits, pushes or opens a pull request. Ask can also do that for you with a confirmed card: see Approving, rejecting and opening pull requests. See also Approval & Deployment.

• If the task changed after Ask summarized it (a new turn or different changes), the dialog says so: “These changes differ from the ones Ask CoderFlow summarized. Review the current changes before approving.”
• If you lose access to the task or your approval permission after Ask offers the button, the click opens nothing and says “This task is no longer available for you to approve. Nothing was opened.”
• If the task cannot be approved when you click, for example because someone else approved it first, the button says why and opens nothing. The task page checks once more right before it opens the dialog; if something changed while it loaded, it shows why instead of opening the dialog.
• The button is not a change: it works with Allow Actions off, has no confirmation card, is never applied automatically and does not appear in Recent actions. It is not saved with the conversation, and one answer offers at most one button.

External MCP clients can read the same review summary (see MCP Server). Agents running inside tasks cannot, but they can still read a task's changed files and diffs.

Approving, rejecting and opening pull requests

With Allow Actions on, you can ask Ask CoderFlow to approve a task's changes (“Approve the failed-task fix and push it”), to reject a task (“Reject that task”), or, once an approval pushed, to open pull requests (“Open pull requests for it”). Ask first reads the task's review summary and tells you what it found, then proposes a card. Nothing happens until you click Confirm, and these cards are never applied automatically.

An approval card names the task, its review revision (the summary Ask read), every repository with the branch it commits to (or the new branch it creates), whether the commits are pushed, and the exact commit message. CoderFlow adds its attribution to the message as the approve dialog does. When you click Confirm, CoderFlow first synchronizes the task's working tree, as the approve dialog does when it opens, then checks everything on the card again. If anything changed since the card was made (the agent or someone in a terminal changed a file, someone approved or rejected the task, a branch moved), nothing is committed or pushed and the card says so; ask again for a new card. CoderFlow then commits exactly the reviewed changes in each repository and, if you asked, pushes each commit to the environment's configured repository. The card is tied to that repository: if someone changes a repository's URL or provider in the environment after the card was made, Confirm refuses, and a change while the approval runs stops it before the next push. Ask never pulls first: if the target branch moved, that repository's push fails and its commit is kept so you can push it to a new branch from the approve dialog.

If a target branch is protected by the repository's protected_branches setting, ask for a new branch (for example the one the summary suggests); Ask cannot push to it directly.

A rejection card names the task and its review revision. Confirming it stops and removes the task container and marks the task rejected; its uncommitted changes, including any made after the review, are discarded. Nothing is committed or pushed, and the task's saved output stays.

A pull request card is a separate step after an approval that pushed. It lists each repository with its source and target branch, and the title and description you asked for. Before creating a pull request, CoderFlow looks for an open one for the same branches and reports it instead, so a pull request is never opened twice. A source branch that moved since the approval is not proposed for review: CoderFlow reads the branch again right before it creates each pull request. If the approval changes meanwhile (for example it is cleared or becomes partly completed), no pull request is opened.

After you confirm, the card lists one receipt per repository: committed and pushed, committed but not pushed, not committed, not attempted, or outcome unknown; for pull requests, opened (with a link), already open, not opened, or outcome unknown. If some repositories succeeded and others did not, the card says the approval partly completed: finish in the task page's approve dialog and do not repeat the change. If the outcome is unknown (for example the server restarted while pushing), the card shows what the task's own approval record says now, marked as read back; CoderFlow never retries it for you.

The same card can appear twice on a page, in the conversation and in Recent actions. If either copy learns that the action is no longer available to you, both show that at once and neither can be confirmed.

Some approvals are intentionally not available in Ask; use the task page's approve dialog instead, which Ask opens with its Open approve dialog button: tasks with documentation publishing, project landings and project-branch deletion, finishing a partly completed approval, more than five repositories, a repository, branch or task name Ask cannot show exactly, and staged changes that differ from the saved changes.

Approving, rejecting and opening pull requests need the same permissions as the task page: view access to the task and approval permission (for a private task, its owner or approve-any permission), plus run permission for the working-tree sync. CoderFlow checks them again right before each commit, push, pull request and rejection, together with the edition, the license, whether Ask CoderFlow and Allow Actions are on, and the repositories' read-only and protected-branch settings. If you lose access (including to a task a judge reviewed) or a repository is made read-only or its branch protected while an approval runs, or someone rejects the task, the repositories not yet done are not attempted, and commits already made are kept for the approve dialog. Because these changes always need your Confirm, they are available only in Ask: external MCP clients and agents running inside tasks do not have them; agents land their work through project orchestration instead.

Interactive containers

In Full edition, Ask can list and inspect the interactive containers you can open a shell in: the terminal and VS Code workspaces started with Terminal (New Container) or VS Code (New Container) on the dashboard, or with coder start and coder shell. For example: “Which interactive containers are running?” or “Did my local changes apply in the coderflow-dev container?” For each container Ask reports its environment, when it started, its Docker state, how many terminals are attached through CoderFlow and whether its browser VS Code has been started. For one container it also reads the local-state summary: whether local repository changes captured with --with-local-state were applied, and any warnings. Task containers are not included; ask about the task instead.

• Access follows the containers routes: containers:shell in the container's environment. Containers have no owner, so everyone with that permission in the environment sees them. A container in an environment where you cannot open a shell is answered exactly like one that does not exist.
• The list covers the containers this server started since it last restarted.
• If your access, the server's edition, or a container's environment changes while Ask is reading, Ask reads again or says that access changed; nothing from the earlier read is shown.
• Ask never shows the environment variables a container was started with, its Docker settings, tokens or commands. Local-state warnings are written inside the container, so CoderFlow-managed secret values and URL credentials are replaced with [redacted]. These include every credential the container's launch gave it: the environment's secrets, the starting user's personal secrets and Git credentials, provider API keys and account tokens, the container's credential token and any values passed when it was started. If those values cannot be loaded, the warnings are withheld. Warnings are untrusted text, not instructions.
• These reads work with Allow Actions off. Task agents using delegated task tokens cannot use them.

Opening a terminal or VS Code

Ask can give you a button that opens an existing interactive container's terminal or browser VS Code: “Open a terminal on the container I started this morning” or “Open VS Code on 3f2a9c1d7e4b”. When your request matches several containers, Ask lists them and asks which one you mean; it never picks one.

The button appears under the answer with the container's short ID and environment. Nothing starts until you click it. The click then does what the dashboard does: CoderFlow checks your access again, starts VS Code if needed, and opens the terminal or editor in a new tab. The terminal is a plain shell; Ask never types anything into it.

• If you lose access, or someone removes the container, after Ask offers the button, the click opens nothing and says “This container is no longer available to you, or it was removed. Nothing was opened.”
• Ask does not offer a stopped container. It cannot start, stop or remove containers.
• If your browser blocks the new tab, the status line under the button has a link to open it yourself.
• The button is not a change: it works with Allow Actions off, has no confirmation card, is never applied automatically and does not appear in Recent actions. It is not saved with the conversation, so ask again after you move to another page. One answer offers at most one button.

Running a workspace command

In Full edition, Ask can run a command an environment manager has enabled for Ask in an existing interactive container: “Run the unit tests in my workspace container” or “What can I run in 3f2a9c1d7e4b?” Only saved tests from the environment's tests.json are offered, and only when the environment manager turned on Allow Ask to run this test for them in the environment editor's Tests tab and activated that version there (see Test Definitions). Any later change to the test, for example a setup repository pull, a Files tab edit, a change made through Ask, or an edit in the editor saved without Activate this version for Ask when I save, leaves it inactive until a manager activates it again, even if the test is later changed back: CoderFlow notes each change when it reads the file or reloads its configuration, which every such change ends with. Only an edit made directly on the server's disk and undone before CoderFlow read the file again goes unseen. Deleting, renaming, importing or cloning the environment (or resetting the Essentials environment) clears its activations too, even if it is created again under the same name. A change that ends an activation (a test changed or removed, an environment removed) applies at once, even if CoderFlow cannot save it to its record of activations. CoderFlow then saves the record again the next time it reads it; if the server restarts before that succeeds (for example, the disk failed or the server stopped while saving), CoderFlow trusts none of the activations it saved before, and every enabled test needs a manager to activate it again. Only if the disk accepts no write at all, recovers, and the server restarts before CoderFlow reads the record again can such a change be lost; check the Tests tab after a storage failure. The Tests tab shows such a test as Not active: changed outside the editor, or not activated yet. Ask never types a command of its own, never turns Allow Ask to run this test on or off or activates a test, and never runs a test that has parameters.

1. Ask lists the enabled commands for that container in a card: each one's name, description, timeout and command ID. Listing works with Allow Actions off.
2. When you ask Ask to run one, it shows a confirmation card. Every run needs your Confirm; runs are never applied automatically. The card shows:
   • the exact container and environment, the command's name, ID and definition revision;
   • the saved command text, exactly as it will run (a command that cannot be shown whole, for example one with hidden characters or over the length limit, is not offered);
   • that it runs as coder from /workspace, after the environment's runtime setup, with this workspace's existing credentials and network access (environment and personal secrets, Git credentials and provider tokens in the container);
   • that it can change files and trigger file watchers or App Server reloads, the timeout and output limits, and that there is no Undo.
3. After Confirm, the card tracks the run. When it finishes, ask for the result: Ask shows the output as plain text in a result card.

Limits and safety:

• Who: you need containers:shell in the container's environment, the same permission as opening its terminal. Running a command gives you nothing you could not already do there.
• Timeout: 300 seconds unless the environment manager set another value, at most 600. One command runs per container at a time and you can have two running; there is no queue. A run whose end could not be checked (for example after a server restart) still counts for its container until its timeout and a 20-second grace period have passed, or the container has been restarted.
• Resources: each process the command starts gets at most twice the timeout in CPU time (at least 10 seconds) and 4 GiB of memory, no core dumps, and a lower CPU priority. A run is stopped once more than 256 of its processes are seen (Process limit reached, its output kept); CoderFlow checks about four times a second, so a fast fork loop can briefly exceed that number. Not limited: total memory across the run's processes, disk use and network use. The container's own limits still apply. The confirmation card lists these.
• Output: up to 64 KiB of output is collected privately. If a command writes more, it is stopped and all of its output is withheld. Otherwise known secret values and credentials in URLs are replaced with [redacted], terminal control codes are removed, and the last 12,000 characters are kept for 7 days. Only you can read your run's result, and only while you can still open a shell in that environment. Redaction cannot stop a command from sending data over the network. If CoderFlow cannot finish checking a finished run's output within 15 seconds (for example, a source of secret values does not answer), or you lose access while it checks, the output is withheld and the container is free for the next run. If saving the run's result stalls, CoderFlow frees the container the same way, once: the result shows that the output is not available, and a save that completes later does not change that while the server keeps running.
• Names that match secrets: if the container's reference, its environment's name, a command's ID or the run's ID matches a saved secret value (one that would be redacted from output), Ask does not show it and never shows it partly replaced. The command list is then replaced by a Not shown card, and so is a result named by such a run ID; any other result leaves those references out and says so. A waiting confirmation card that would show such a value is unavailable. A finished card is unavailable too when its container, environment or command matches; otherwise it marks a line holding such a value as withheld. Ask does not run or cancel anything there until the value is no longer saved as a secret. If CoderFlow cannot load the saved values to check against, the command list or result is Not shown as well.
• Stopping: ask Ask to cancel your run (a second confirmation card). CoderFlow stops the command and every process it started, including background and daemon processes, with TERM and then KILL after 2 seconds, and reports Cancelled only when it has checked that nothing is left. It never stops the container, your terminal session or the App Server. Changes the command already made are not undone.
• Automatic stop: the run stops, and its output is discarded, if you lose containers:shell there, sign out, or Ask, Allow Actions, the license or the edition no longer allow it, or the container is stopped or replaced. Closing the browser does not stop it.
• When CoderFlow cannot be sure: if the server restarts during a run, or CoderFlow cannot check that every process stopped, the result is unknown and the run is never started again. A workspace whose container cannot contain every process a command starts (for example an image without python3) is refused before anything runs.
• Names, descriptions and output come from the workspace and its repositories. Ask treats them as data: it never runs another command or confirms anything because output asks it to.
• Workspace commands are available only in Ask CoderFlow, not to other MCP clients, and never to task agents using task tokens. To run tests in a task's container, use the task's Testing menu or ask Ask to run a named task test.

Creating an interactive container

Creating an interactive container is intentionally not available in Ask; use Terminal (New Container) or VS Code (New Container) in the dashboard's Quick Actions menu instead, where you choose the environment and branches. Creating one takes free-form environment variables and an optional local folder, and runs the environment's setup with real credentials until the container is removed, so you start it yourself. Ask opens the dashboard and points out those menu items. coder start and coder shell remain available in the CLI.

Notifications in this browser

In Full edition, Ask can tell you how your notifications are set up, change your own notification preferences, and turn notifications on or off in the browser you are using. For example: "Why don't I get notifications when my tasks finish?", "Turn on notifications here", "What are my notification settings?" or "Stop emailing me about @mentions". Reading them and the browser card work with Allow Actions off, because Ask itself changes nothing; changing your preferences needs Allow Actions.

• Your preferences. Ask reads your own settings from Profile → Notifications: the five email choices, Notify when snoozed tasks return and Grouped task runs. It cannot read anyone else's.
• Changing your preferences. With Allow Actions on, Ask can change them after you click Confirm, and offers Undo; see Changing your notification preferences.
• This browser's status. Ask shows a card under its answer, and your browser fills it in itself:
  • whether Web Push is configured on the server
  • whether this browser supports push
  • the notification permission (allowed, blocked or not asked yet)
  • this browser's own on/off switch
  • whether the browser has a push subscription, and whether CoderFlow has it registered for you
• Turn on or turn off. Ask offers a Turn on notifications in this browser or Turn off notifications in this browser button. Nothing changes until you click it. Clicking runs the same steps as Profile → Notifications → Enable on this browser: the browser may ask for permission, and CoderFlow subscribes or unsubscribes this browser. The card then shows the permission, the subscription and the registration as separate lines. If the browser is still finishing the change when the card reports, the card says so instead of showing notifications as on or off; click Check again in a moment. A second change, such as Turn off right after Turn on, or one made in another CoderFlow tab, waits until the first has finished, and then the second one is what applies. In an older browser that cannot coordinate these changes between its tabs, Turn off removes CoderFlow's registration but leaves the browser's own push subscription in place, and the card says so. If the browser later renews that subscription on its own, CoderFlow registers it again for whoever is signed in; turn notifications off again, or use a current browser. Only this browser on this device is affected, not your profile or your other devices.

Ask sees the card's results in its next answer, as words such as "permission: granted" or "registered: no". Your browser's push address and keys are never shown to Ask or saved with the conversation.

• If notifications are blocked for CoderFlow in your browser, the button cannot change that. Allow notifications for the site in the browser's site settings (usually the icon next to the address), then click Check again.
• The card acts only for the user Ask offered it to. If you were signed out, or someone else signed in, after Ask offered the button, the card refuses and changes nothing. If that happens while the card is working, before CoderFlow has accepted the change, CoderFlow refuses it, and the card leaves this browser's on/off switch as it was (after a Turn off, it puts the switch back). A change CoderFlow had already accepted stands for this browser, as it does with the profile toggle, but the card does not show its result. A permission you allowed at the browser's prompt stays allowed: that is the browser's own setting for the site. Results read earlier for that user are removed from the cards and from the conversation, at the latest before your next question is sent, so Ask never sees another user's results. Signing out in another CoderFlow tab removes them too. Ask again after signing in.
• The card checks whether notifications can reach this browser. It cannot tell whether one was shown or read.
• A conversation restored on another page shows the card again, but reads nothing until you click Check again or the button.
• Inside a task's app preview the card refuses; open CoderFlow itself.

Changing your notification preferences

With Allow Actions on, Ask can change the same seven preferences that Profile → Notifications shows, and only your own: there is no way to name another user.

• Only what you asked. The card lists just the preferences you asked to change, each with its current and new value (for example Email: @Mentions On → Off). Nothing changes until you click Confirm, even at the highest Auto-Apply level. Confirming saves those and nothing else: your name, email, other notification preferences and other profile settings stay as they are, even if you change them meanwhile in another tab.
• Checked at Confirm. If one of those preferences changed after the card was prepared, for example in Profile → Notifications in another tab or on another device, even if it was changed back, Confirm saves nothing and says so; ask again to see the current values. Confirm also needs the same sign-in that prepared the card: if you signed out, or confirm from another device, nothing is saved. Turning off Ask CoderFlow or Allow Actions, or a license or edition change, also stops it, up to the moment it saves.
• Shown only while allowed. These cards, their receipts and Undo, also in Recent actions, appear only in your own current sign-in, and only while Ask CoderFlow, Allow Actions, the edition and the license allow the change. Otherwise they show as unavailable. Once all of these allow it again, the card shows what happened.
• Undo. The card offers Undo for 24 hours, and it works like Undo of environment and automation changes: it puts back the values the change replaced, and if you or someone signed in as you changed one of them since, Undo leaves it as it is and offers Review a change back. Undo also needs your current sign-in.
• Clicking Confirm twice never saves twice. If the server stops while saving, the card says whether the change was saved, checked against the saved preferences; it is never repeated.
• Profile → Notifications shows the new values the next time you open it. A profile dialog that was already open in another tab still shows the values it loaded; if you save it, those values are saved again, and Ask's Undo then leaves them alone. Close and reopen it before saving.
• Your browser's own notification switch is separate: use Turn on / Turn off notifications in this browser for that.
• Only Ask can make this change, because it needs your Confirm: external MCP clients and agents running inside tasks cannot change preferences (see MCP Server).

Actions

In Full edition, Ask CoderFlow has the shared MCP tool catalog even when the external MCP endpoint is disabled. Read-only lookups remain available with Allow Actions off; turning it on allows changes:

• Look up your environments, templates, task groups, tasks, task output and files, and objectives, and IT requests (see Reading IT Requests). For example: "Which of my pinned groups finished today?" or "What did the judge recommend for the login fix?"
• Change things, with Allow Actions on:
  • rename a task or task group
  • pin or unpin tasks and groups on your own Pinned list
  • snooze or wake your pinned work
  • create or update objectives
  • launch a saved objective, or delete one (see Launching or deleting a saved objective)
  • start a task
  • stop or interrupt a running task, or resume its paused follow-up queue, and start, stop or restart its configured app server (see Controlling a task's runtime)
  • send a follow-up to a task
  • edit the text of, or remove, a queued follow-up (see Editing or removing a queued follow-up)
  • fork a task
  • run an AI judge or review
  • build an environment image or run a named test on a task (see Building images and running named tests)
  • run a saved automation once (see Running and checking automations)
  • test a saved SQL or SSH connection, or cancel that test (see Connection and Portal readiness)
  • execute a deployment profile as a deploy task, or run or cancel an environment deployment (see Environment-run deployments)
  • change common environment settings and resources, such as automations, templates, files, environment skills, which skills an environment uses, and memory; less common settings Ask only reads and explains (see Maintaining an environment)
  • mark or clear task winners and losers
  • approve or reject a task's changes, and open pull requests after an approval that pushed (see Approving, rejecting and opening pull requests)
  • change your own notification preferences (see Changing your notification preferences)
  • run a test an environment manager enabled for Ask in an interactive container, or cancel your run (see Running a workspace command)

Ask points to common task controls instead of changing them. For comments, sharing, custom fields, rewinding to a turn, resubmitting or deleting a task, starting its stopped container, the agent's questions, the reply box's options, discarding a file, AI Judging's auto-review, review requests and judge feedback, and your computer on a task, Ask opens the task and shows you the control; see Ask shows you where. It does the same for launch options, test tasks, the board's view controls, moving a task on Canvas, Build Images..., the server logs and your time on My Work (see The dashboard, Build Images, server logs and My Work). The same holds for IT request work on the Requests page: replies, status, assignee, priority, internal notes, linked work, task launches and AI drafts (see IT Requests).

Ask points to some environment checks and to publishing, too. Testing an automation's SCM poll, a connection's library list, special authority, RAS and Profound UI checks, Portal launch trust setup, and committing and pushing setup repository changes are done on the Environments page; Ask opens it and shows you the control (see Ask shows you where).

Existing hand-offs stay available. Installing or updating a skill, or changing a queued follow-up's attachments, model settings, scheduled delivery or send-now, uses the existing page or queue-panel hand-off. Its button opens the page or dialog; you review and act there. The queue hand-off does not open a rewind dialog at a particular turn.

Rarely used setup and maintenance stay outside Ask. Ask can explain these from the documentation, without offering to perform them or pointing them out:

• transferring child tasks to another lead; task display reparenting, regrouping and container protection; deleting another person's comment (there is no Web UI control for that deletion)
• an environment’s auto-tier model map (the environment editor has no control for it)
• repository seeding, source import, cherry-pick, merge and revert
• testing an unsaved automation poll configuration; webhook token rotation/copy and integration connection or testing
• Bridge provisioning/removal, TLS trust, key setup and tests with unsaved credentials
• server prune, update, restart and container cleanup; clearing all environment memory
• direct documentation publication, forced publication and exact-commit publication/retry
• standalone interactive-container removal, which uses the CLI's coder containers clean
• IBM i source import, build-rule generation, deployment recovery and hold clearing, and IBM i installation and setup

Transferring child tasks to another lead is rarely used: Ask explains it from Project orchestrator, without a write or page pointer. Use Transfer… in the lead’s Child tasks box or Take over… on its fork. Task agents can still use the MCP transfer tool.

Existing reads remain available, including task comments, automation history, webhook deliveries, saved readiness and server diagnostics. Existing writes also remain: Ask can run a saved docs-publish automation through Run Now and create, change or delete its automation definition. Those saved-automation operations are separate from direct publication of exact approved commits. Ask cannot explain a skipped run from a history record that does not exist.

The existing page flows for server settings, users, teams, roles, access and environment setup remain as described in Reading settings and diagnostics, Changing users, teams, roles and access and Maintaining an environment. Ask does not prepare, publish or revoke media; the task that prepared an image does that with its own tools. IT request changes are made on the Requests page, where Ask points to them; additional Portal/IBM i management remains on their current pages; Portal's own assistant still answers business questions and helps author reports.

Each change appears as a card under the answer. The card names what will change, such as the task's current name, and lists every value the change will use. For a new task, that includes the environment, agent, model and the full instructions. For a change to an environment's setup, such as an automation, template or skill, the card lists only the fields that change, and how many stay the same. A short value shows as old → new. Longer text shows line by line, removed lines in red and added lines in green, with unchanged lines folded away until you open them. Show full before / after shows the whole item before the change and everything the save sends. A value Ask cannot show, such as a stored password, appears as Hidden — may change when the change includes it; check it in the environment editor. Nothing changes until you click Confirm; Cancel discards the change. When an answer proposes two or more changes, Confirm all runs them in order. It stops at the first one that does not complete.

After a change runs, the card shows the result. Cards for new tasks link to them, including tasks that started before a launch failed, and then follow those tasks until they finish (see Following the work Ask started). A fork in which any copy failed shows as failed, with links to the copies that worked.

The result text is the same for everyone who can see the card: other than names you entered, it never names a task, deployment, build or other item by ID or by name. The card's links and tracked work name them, each only while you still have the access that item itself needs. For example, if you can run deployments in an environment but cannot view its tasks, a deployment card says Deployment started and shows the deploy task as unavailable instead of linking it.

Ask CoderFlow knows what happened when you ask a follow-up question. To work with something a change started, such as reading a task's output, it looks the work up again, so it sees only what you can still open.

A proposal expires after 15 minutes, even if nothing else happens on the server in the meantime; ask again to get a new one. One answer can make at most three changes. Cards move with the conversation to other pages: a waiting card can still be confirmed there until it expires. See Recent actions and restoring cards for what survives a reload or a server restart.

Some results tell you to check before trying again:

• Partly completed: some of the change happened, for example two of three tasks started. The card links what did happen. Do not repeat the change; check the result and ask for what is still missing.
• Outcome unknown: CoderFlow sent the change but did not get an answer, for example because the server restarted or a task start took too long. Check the service (your tasks or the environment) before retrying. Ask CoderFlow never retries it for you. Where CoderFlow can check what happened, for example in a task's approval record or in your saved preferences, the card shows what it found, and nothing runs again.
• Saved — verification failed: the change was saved, but reading it back afterwards failed. Check the result; do not save it again.

Confirm all stops at a partly completed or unknown result. A change that was saved but failed verification counts as completed, so Confirm all goes on to the next change; check that result afterwards.

Only renames, pins and snoozes, and starting tasks, can be applied without a card, and only at the level you choose (see Auto-apply). Every other change always requires Confirm, even when auto-apply is enabled, including objectives (creating, editing, launching and deleting them), environment changes, notification preference changes, queued follow-up edits and removals, task runtime controls, image builds, named test runs, workspace command runs and cancellations, automation runs, connection tests, deployments, task approvals, rejections and pull requests, and winner/loser marks. A deployment result reports that work started; it does not mean the deployment has finished. The card follows either its deploy task or its separate environment deployment to the recorded result.

Undo

Renames, pins and snoozes have an Undo button. It reverses exactly what that change did, including any snooze a pin change cleared, and leaves other edits to the same tasks alone. When a change applied only partly, Undo reverses the part that applied. If someone has changed the same thing since, Undo makes no change and says why. If someone changes one of those tasks while Undo is running, Undo stops there and keeps their edit. It tells you how many of the tasks it had already restored; the rest are left as they are. Undo also restores whether a name was generated automatically, so generated names keep updating as before. This Undo is kept only while the server runs: after a restart it is no longer offered.

Changes to a few environment and automation settings, and to your own notification preferences, offer a longer-lived Undo, described below and in Changing your notification preferences. No other change has an Undo button; ask for a new change to set things back.

Undoing environment and automation changes

A confirmed change to an environment's description, default agent or time zone, or to an environment automation's on/off state, schedule or time zone, offers Undo, as long as the change touched only those fields. The card says what Undo puts back and until when: Undo is available for 24 hours after the change, also after a page reload, on another device (from Recent actions) and after a normal server restart. If the server was stopped abruptly (for example killed or out of memory), Ask can no longer confirm that nothing changed in the meantime: earlier Undos then show as unavailable right away, without a click, instead of guessing.

• Undo puts back exactly the values the change replaced, and only those fields. An edit made since to another field, another environment or another automation is kept, and does not stop Undo.
• If someone has changed one of the same fields since, even back to the value Ask set, Undo leaves that field as it is and says so: it never overwrites a newer edit. The card then offers Review a change back, which prepares a normal proposal that sets the earlier value, checked against the current settings; nothing changes until you confirm it. If that proposal expires, is cancelled or is refused because the settings changed again, Review a change back prepares a new one from the current settings.
• When Undo restores some fields but has to skip others, it says how many it restored and how many it skipped, and why (changed since, or you can no longer change them).
• Undoing an automation's schedule or on/off state does not reverse runs that were already triggered, and does not make up runs that were skipped meanwhile; the card says so.
• Undo is itself a change: it needs the same permissions as the change it reverses (for an environment, environments:manage and environments:view_details; for an automation, also automations:manage), and Ask CoderFlow, Allow Actions and a valid license. If you cannot make it right now, Undo says so and stays available until it expires. It is never applied automatically, it runs only once (a second click shows the same result), and it is listed in Recent actions as Undo change. An Undo cannot itself be undone; ask for a new change instead.
• If an open environment editor has unsaved edits, Undo waits until you save or discard them, as Confirm does, and the editor refreshes afterwards.
• No Undo is offered for a change that also touched other settings, or for creating or deleting something; the card says why. Ask for a new change to set things back.
• Ask never keeps text that contains one of the environment's secret values or a password in a URL. A description like that is not kept for a restart, and if the value Undo would put back contains one, no Undo is offered. If an earlier value becomes a secret later, Review a change back does not propose it; set it in the editor instead.
• If Ask cannot tell yet whether an interrupted Undo was saved, Review a change back says so instead of guessing; check the current settings first.
• If the server cannot record which values a change replaced, the change is still saved, but it gets no Undo; the card says why.
• Ask keeps your 25 most recent actions, and each Undo counts as one. When you make many changes, an older change can lose its Undo before its 24 hours are up; its card then says Undo is no longer available.

Following the work Ask started

When Ask CoderFlow starts work for you (a task, a follow-up, a fork, an AI judge or review, or a deployment), its card first says the work started, then follows each task it started until that task finishes:

Card label	Meaning
Started — waiting to run	The task is queued, for example until an agent slot is free. A queued follow-up waits for the task's current turn to end.
Started — running	The task is running.
Finished — succeeded, failed or cancelled	Every task finished that way. Cancelled means someone stopped it.
Finished — mixed results	The tasks finished differently, for example one succeeded and one failed. Until every outcome is known, the card says some results not known yet instead.
Partly started	Only some of the requested tasks started, for example one of two agents. Do not repeat the change; ask for what is missing.
Started — state unknown	CoderFlow cannot tell yet, for example a later turn started on the task before this one was seen to end. Open the task to check.
No longer available	You can no longer open the task (it was deleted, or your access changed). The card shows nothing more about it.

Each started task has its own line with a link to its page (for a deployment, Open deployment output; for a review, Open review), and a group link when the work started several tasks. A fork shows Ready once it is created: send it a follow-up to start work. For an AI review loop, the card follows the judge tasks the launch started; later rounds appear on the task group's page. Image builds, named test runs, automation runs, readiness checks and environment deployments are followed the same way until they finish.

The card has no stop button of its own. While a task is running and you may stop it, the card offers Stop on task page, which opens the task page where Stop works as usual. You can also ask Ask CoderFlow to stop the task; see Controlling a task's runtime.

The card updates by itself while the page is open, more slowly the longer nothing changes, and pauses while the page is hidden or after six hours; Check now looks again at once. Closing the panel, reloading, signing in on another device or a server restart does not lose it: the card, and its entry in Recent actions, show the current state when you come back. Each look checks your current access to every task.

You can ask Ask CoderFlow what happened to work it started, for example "Did the deployment you started finish?". It reads the same tracked state, and says when a state is unknown rather than guessing. When the tracked work has finished, the conversation records how it ended. If a read-only check after a restart finds that an interrupted launch was never recorded, the card says Nothing was started; it does not retry the launch.

Dependent workflows

When you ask for a short series of changes in one environment where a later change depends on an earlier one, Ask CoderFlow can propose them together as a workflow of up to five steps. For example: "Switch this environment to Codex in Berlin time, update the release template, then start a release check from it", "Change the build setting, rebuild the image, then start a smoke-test task", or "Create a release-notes skill and assign it to this environment". For a single change, or changes that do not depend on each other, it keeps proposing ordinary cards.

A workflow appears as one card that lists its steps. Each step shows what it changes, the values known now, and which values come from an earlier step: for example, the skill reference that step 1 will create, or the template that step 2 saves. Nothing changes when the workflow is proposed.

• Start workflow prepares the first step's card. Starting a workflow is not a confirmation: each step runs only when you click Confirm on its own card, which shows its actual values and target. Confirm all and auto-apply never run a workflow step.
• After a step completes, the next step's card is prepared from the plan and the results recorded so far. A value an earlier step produces, such as the ID of a skill it created, is taken from that step's recorded result, never typed in by Ask CoderFlow. A step that needs such a value says Waiting for input until the value exists.
• If what a step changes was edited after the plan was shown (by someone else, in another tab or by another client), its card is prepared from the current state and marked Revised: review it before confirming. A change to the repository list keeps entries someone else added or changed meanwhile; if you both changed the same entry, the step waits for input instead of guessing. A step whose card keeps being refused because its target keeps changing waits for input after several tries; skip it, or ask again.
• If a step fails, is cancelled or is skipped, the steps that depend on it are skipped. An unknown outcome makes its dependents wait; independent steps are still offered. Steps that already ran keep their results: there is no automatic rollback. A step whose outcome is unknown stays that way until CoderFlow can check it (for a task start, by looking up whether the start was recorded); it is never retried.
• Skip step skips a step that has not run; Cancel remaining steps cancels every step that has not run. Neither undoes a step that already ran.
• A step that starts a task follows that task until it finishes, like any task Ask CoderFlow starts. A step that depends on it waits for it to succeed, and waits as well (it is not prepared, and its card cannot be confirmed) while you can no longer open that task; it continues once you can. Steps that do not depend on it continue meanwhile.
• A step that builds the environment's image uses the normal build card: it is prepared only after the changes before it in the workflow have saved, shows the same checks, and builds only when you confirm it. While the build runs the step shows Building with a link to the build; a task started later in the workflow waits until the build succeeds, and is skipped if the build fails or its card is cancelled. If the server restarts during a build (CoderFlow confirms the build is gone when it checks again a little later), or a build start is interrupted, the step's outcome is unknown: it is never built again automatically, and the steps that depend on it wait; check the environment's build history, then skip them or ask again. If your access changes while you confirm a step, the step does not run and nothing is changed: its card is prepared again when the workflow can continue, except a build that was about to start, which is marked as refused (ask again to build). A workflow builds the image at most once, and only for its own environment.
• A step that was saved but could not be confirmed by reading it back shows Saved — verification failed: check the result, and do not save it again. A workflow with such a step says it finished, not that every step completed. Assigning a skill is confirmed only when the environment's skill list read back after the save includes it.

Each step uses the same tools, permissions and checks as a single change. Workflows can change environment configuration and repositories, skill assignments, files, templates, environment skills and their files and automations, build the environment's image, and start a task from a template. A workflow with a build step needs environments:build on its environment: without it, the workflow shows as unavailable and none of its steps continue. Deletions and publishing setup changes are not workflow steps, and neither is anything Ask only reads, such as an environment's status or auto-tier model map, Portal settings, connections, MCP servers or secrets (see Maintaining an environment). After a step saves environment setup, the workflow card shows whether the environment's setup changes are still only local or already published; publishing them remains a separate operation in the environment editor.

A proposed workflow expires if you do not start it within 15 minutes; a started workflow keeps its remaining steps for a day. Each step's card is a normal card: it expires after 15 minutes, and the workflow then prepares a fresh one when you come back. The workflow card survives a page reload, another device and a server restart, and resumes from the steps' recorded results without running any step again. A step with file, template or skill text that had not run yet when the server restarted waits for input after the restart, because that text is not kept: skip it, or ask again. That text is held in the server's memory only while the workflow can still run, and Ask refuses a new workflow when it is holding too much such text; start or cancel an open workflow first.

Auto-apply

To skip the confirmation step, choose a level from the button above the Ask CoderFlow input box. The choice applies to the current conversation only. It carries over when the conversation moves to another page, and resets when you start a new conversation.

Level	What applies without a card
Confirm every change	Nothing. This is where every conversation starts.
Apply reversible changes	Renames, pins and snoozes. Each still appears in the conversation, with Undo.
Also start up to 3 tasks	Reversible changes, plus starting tasks, follow-ups, forks and judge or review runs, up to three agent runs in the conversation. After that, each one needs your confirmation again. An AI review loop, which can run many rounds, always needs confirmation.

Administrators set the highest level users can choose with Auto-Apply Limit. Choose None to require a confirmation for every change. Every other kind of change always needs confirmation, at every level (see Actions); which changes can be undone is described in Undo. Stopping an answer stops any further automatic changes.

If starting a task takes longer than 10 minutes to respond, the card says the outcome is unknown. Check your tasks before asking again, because the start may still complete.

Recent actions and restoring cards

Most changes are kept on the server until they are decided: renames, pins and snoozes, template-based task starts, judge and review runs without custom instructions, environment setting changes, changes to an automation's on/off state, schedule or time zone, notification preference changes, task runtime controls, image builds and named test runs, workspace command runs and cancellations, automation runs, saved-connection tests, environment-run deployments, task approvals, rejections and pull requests, queued follow-up edits and removals, and objective launches and deletions. Their cards survive a page reload, a new tab and a server restart. A waiting card shows the change again for review, and still needs your Confirm. An environment change proposed before a server restart can still be confirmed if its settings have not changed and the proposal has not expired. Changes to hidden values also invalidate a proposal; read the latest settings and ask again in that case.

Other changes, such as a task with instructions you wrote, file, template or skill edits, and deploy-task launches, work as before but are kept only by the running server. Their cards say Not restorable after server restart. After a restart, a card that was still waiting becomes unavailable: ask again if you still need the change. A card that was running when the server restarted says Outcome unknown, because the change may have been applied: check the service (your tasks or the environment) before trying again. Work these changes had already started is still followed after a restart: the card and its Recent actions entry become read-only, can never be confirmed or run again, and keep showing the state of the tasks they started.

Click the Recent actions (clock) button at the top of the Ask CoderFlow panel to list your recent changes, newest first, with their status and links to the tasks they started and the environment they changed. Your recent workflows are listed first, with each step's state; Show workflow opens the workflow card, and a step's own entry says which workflow step it is. A waiting change can be reviewed and confirmed from there, including on another device. Older entries load with Show older actions. The list shows only your own changes, checked against your current access: if you can no longer see something a change targeted, its entry shows as unavailable without its details. A workflow step's entry names its workflow only while you can still see that workflow, and opening a workflow you can no longer see clears the details of its entry and of its steps' entries.

Changes Ask made, or proposed, before it stopped making a kind of change (for example changing users, teams, roles or access, renaming an environment, changing an MCP server or a webhook, installing, updating or separately assigning a skill, or publishing an image) appear as one card, Earlier Ask change (now made in the CoderFlow UI), marked No longer made in Ask, in the conversation and in Recent actions. The card is read-only: it says only that Ask no longer makes such changes and where to make them now, never names or details of what it changed. It cannot be confirmed, whether it was still waiting or already done, and nothing it describes runs again. It offers neither Confirm nor Cancel. If a card that was already open still shows them, Confirm says Ask no longer makes the change and changes nothing, and Cancel withdraws a change that was still waiting; left alone, a waiting one expires. Make the change on the page the card names.

If your server was rolled back to this version from a later CoderFlow version, changes that later version proposed or made, of a kind or in a form this version does not know, appear as one card, Ask change from another CoderFlow version, marked Made by another CoderFlow version, in the conversation and in Recent actions. Only you see your own. The card is read-only and names nothing of the change: it cannot be confirmed or cancelled, nothing in it runs on this version, and it is kept as it was, so it shows normally again after the server is upgraded again. Check the change where it applies in the CoderFlow UI. See Rolling Back to an Earlier Version.

An entry stays this way for good, whether the change was waiting, done, cancelled or expired, and after the server restarts. That includes a change to an environment's Status or Portal settings that Ask still held when this version first started, and every earlier Ask test of an automation's SCM poll, setup repository commit and push or push retry, and connection check other than a saved SQL or SSH test (library list, authority, RAS, Profound UI, and Portal launch trust steps). Their entries say where you do it now, such as Test Poll in the automation's editor or Commit & Push on the Environments page. Changes to an environment's other settings, automation runs and saved SQL or SSH tests keep their usual entries. One kind of history keeps its usual entry too: a finished change from before this version that recorded only that the environment's settings changed, not which setting, or a connection check that had already been cleared to a short status record and no longer says which check it was. Like any finished change, it can never be confirmed again.

If the server restarts while a change is running, its entry says Outcome unknown. For a task start, Check status looks up whether the start was recorded and links the tasks it created; it never starts anything. After a restart, Undo is no longer offered for renames, pins and snoozes made before it; the 24-hour Undo of environment, automation and notification preference changes stays available (open the change with Show Undo). If the server restarted while an Undo was running, the change's card says what the Undo had restored, checked against the saved settings; Undo never runs again by itself, and if it had changed nothing yet, Undo is offered again.

The server keeps decided changes for up to 30 days and short status records for up to 90 days; under load it removes the oldest first, and an entry may then say its history detail was pruned. A removed entry can never be confirmed again.

Controlling a task's runtime

Ask can stop or interrupt a running task, resume a paused follow-up queue that has entries, and start, stop or restart its configured app server while the task container is running. Each card names the exact task, operation and consequence. These controls require Allow Actions and Confirm, even with auto-apply on. Stop, Interrupt and the app-server controls need tasks:execute on the task; Resume needs tasks:change.

Stopping ends the current agent turn and stops its container; queued follow-ups stay paused. Interrupting normally pauses the queue too; you can explicitly ask to send the queued follow-ups after interruption. Resuming lets the queue deliver when the agent is idle, which can start another agent turn. Stopping or restarting an app server interrupts its users.

Ask checks your current permissions and the task state again when you confirm, then reports the current task, container, queue and app-server state. An already stopped container or a queue that is no longer paused results in no change. A Stop or Interrupt card acts on the task's turn at the time you confirm it. If a newer task turn or app server takes over while the confirmed control is being sent, Ask refuses it. An app-server control is also refused when the app server's state no longer matches the state shown on the card. Confirming the same card twice does not run it twice. If access is removed, the card becomes unavailable and withholds result details, even if the operation already finished. An unrelated user’s permission update does not turn your successful control into an unknown result: Ask checks your access again before starting work and before returning its result, without repeating the control.

If Ask cannot tell whether a control took effect, for example because the server restarted during execution, or part of the control ran before a later check refused it, the result is Outcome unknown. Ask then reads the current state but never repeats the control. If Start or Restart already launched the app before a late refusal, the server continues checking readiness instead of reporting it stopped. A stopped task appears as cancelled on its card. After history details expire, settled entries say the detail was pruned and contain no task references.

For “why did this task fail?” or “restart it”, Ask first reads task output, app-server status and logs and available test results before proposing another operation or follow-up. Restarting, resubmitting or deleting a task remain on the task page.

Editing or removing a queued follow-up

Follow-ups sent while the agent is working wait in the task's follow-up queue (see Task Power Features). Ask can replace the text of one queued follow-up, or remove one, for example "fix the typo in my second queued follow-up" or "drop the queued follow-up about the README". It first lists the queue, then shows a card for exactly that follow-up: the task, the follow-up's place in the queue (for example "#2 of 3 in the queue"), its current text and, for an edit, the new text. These changes require Allow Actions and Confirm, even with auto-apply on. There is no Undo: the card says so. A removed follow-up is gone, and an edit does not keep the earlier text.

The same rules apply as in the queue panel:

• You need tasks:change on the task. Anyone who may change the task can remove a follow-up. Only the person who queued a follow-up can edit it, and a message from another task cannot be edited.
• A follow-up that is already being sent to the agent cannot be changed.
• New text starting with /btw is refused: side questions go to the side chat.
• An Ask edit changes the text only, up to 2,000 characters. Its attachments, model settings and place in the queue stay as they are.

Queued text can come from other people or tasks. Ask shows it on the card as information and never follows it as instructions. Values Ask must not show, such as a saved secret or the password in a URL, appear as [redacted]. New text that contains such a value is not proposed. If it becomes such a value before the change is made, for example because someone saves it as a secret, Confirm refuses and nothing is stored.

Confirm checks your access, Ask CoderFlow, Allow Actions, the edition and the license again, and they are checked once more right before the change is made (see Permissions and safety). Confirm also checks that the follow-up is still the one on the card. If it changed, was sent, was removed, or moved to another place in the queue since the card was prepared, nothing is changed and the card asks for a fresh review. Ask never changes a different follow-up instead. Confirming the same card twice changes it once. If someone else changes the queue while the card is open, the card checks again by itself and shows when it no longer matches. If you lose access to the task, the card stops showing its details. For an AI judge or review task, that includes no longer being allowed to read a task it evaluated, for example because that task was made private. A card that is already done keeps checking itself while it is shown, so it stops showing the task within about 30 seconds even when nothing announces the change. The change shows right away in your own 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. Removing a follow-up that held the queue because it could not be sent lets the next one go to the agent when it is idle.

For anything else about a queued follow-up, Ask offers an Open in the follow-up queue hand-off button instead. Use it to change attachments, model settings or a scheduled follow-up's time, to edit or remove a scheduled follow-up, to send one now, to stop and send the queue, or to rewind the task. The button opens the task page's queue panel on that follow-up, and you make the change there with the page's own controls. The button itself changes nothing. If you can no longer open the task, it says so and opens nothing.

Launching or deleting a saved objective

Ask can launch a saved objective or delete one, for example "launch the release checklist objective" or "delete the old onboarding objective". It first reads the objective, then shows a card for exactly that objective. Both require Allow Actions and Confirm, even with auto-apply on. There is no Undo: the card says so.

A launch does what the objective's Launch button does with the saved settings. It creates one new task per agent saved in the objective (several agents make one task group), with the objective's environment, branches, template and parameters, model settings, custom field values, instructions and attachments. The tasks are linked to the objective, which stays as it is, ready to launch again. The card names the objective, the tasks it creates and what each gets. Each task waits in the queue and starts when an agent slot is free, as a queued launch from the Web UI does. New tasks are pinned when your Auto-pin new tasks preference is on.

The one launch option is Discard after task creation: ask for it ("launch it and then delete it") and the objective is deleted once its tasks exist. To change anything else first (agents, branches, instructions), edit the objective in its editor, or add launch notes or stage the tasks there; Ask does not change the saved settings when it launches.

Deleting an objective does what its Delete does: the objective and its attachments are deleted. Its sub-objectives and the tasks launched from it are not deleted; they stay, shown at the top level and as standalone tasks. The card shows how many attachments are deleted and says that sub-objectives and launched tasks are kept.

The same permissions apply as on the objectives page:

• You need to be able to open the objective (tasks:view, or tasks:view_any for someone else's private objective).
• Launching a shared objective needs tasks:execute in its environment. Launching a private one needs tasks:execute as its owner, or tasks:execute_any.
• Deleting, and Discard after task creation, need tasks:delete as the objective's owner, or tasks:delete_any, for a shared objective too. Without the delete permission, Ask can launch the objective but not discard it.
• An objective you cannot open is reported the same as one that does not exist.

Confirm checks your access, Ask CoderFlow, Allow Actions, the edition and the license again, and they are checked once more right before each task is created and before the objective is removed (see Permissions and safety). Confirm also checks that the objective is still the one on the card. If it was edited, moved, launched or deleted since the card was prepared, nothing is launched or deleted and the card asks for a fresh review. Confirming the same card twice launches once.

If a launch stops partway, for example because the objective is edited or deleted after the first agent's task was created, the card says that only some tasks were created; those tasks stay. If the tasks were created but the objective could not be discarded, the card says it was kept. If the outcome is not known (the server stopped during the launch), the card says so and shows the tasks that launch created; it never launches again by itself. Likewise, if the server stopped while a deletion ran, the card says the outcome is not known: check the objectives list to see whether the objective is still there. Once it is gone, the card no longer names it, and only you see it, while you may delete objectives in that environment. It never deletes again by itself. The card follows the started tasks like any task Ask starts (see Following the work Ask started); its text names no objective or task.

If someone else edits or launches the objective while the card is open, the card checks again by itself and shows when it no longer matches. If you lose access to the objective, or someone else deletes it, the card stops showing its details. A card whose own change deleted the objective keeps its result but no longer names the objective. A card that is already done keeps checking itself while it is shown.

Ask never shows or stores a value it must not show, such as a saved secret, on these cards. If the objective's name or a setting the card would show contains one, Ask does not propose the change, and if such a value becomes known just before the change is made, nothing is launched or deleted.

Permissions and safety

• Lookups and changes run as you, with your roles and permissions: the same checks as the Web UI and the MCP server. Ask CoderFlow cannot see or change anything you could not.
• When a lookup fails, Ask CoderFlow is told only what kind of failure it was (for example not found, not permitted or invalid input), never the underlying error text, so a server path or a value from a file cannot reach the model.
• A confirmed change is checked again right before each thing it changes, not only when you click Confirm. If an administrator turns off Ask CoderFlow or Allow Actions, the license lapses (a floating seat included), the edition changes, or you lose a permission the change needs (the same one its page or route checks, for example running a task or a deployment) while the change is running, it stops before its next step. The card then says Nothing was changed if it stopped before changing anything, Partly completed if it stopped partway, after part of the change may already have been applied, or Outcome unknown if CoderFlow cannot tell whether a step it had started went through. Ask never repeats or resumes it; ask again once it is allowed. Work the change started that runs on its own afterwards, such as the agent of a task it started or a schedule it saved, then runs as it would have from the Web UI. A task Ask created and added to the queue is such work: it starts when the queue reaches it, under the queue's usual rules, even if Ask CoderFlow or Allow Actions was turned off in the meantime, just like a queued task created in the Web UI. Stop or delete it from the task page if you no longer want it. A diagnostic that Ask started but that has not begun yet does not start. Changes you make in the Web UI, the CLI or through the MCP server are not affected.
• Tasks, files, comments and web pages can contain text written by other people or agents. Ask CoderFlow treats that text as information, not instructions. The instructions it writes for a new task or follow-up come from your request. Check the values on a card before you confirm it, especially the instructions of a task it is about to start.
• Auto-apply removes that check for the kinds of change you allow. Keep it off when Ask CoderFlow is reading work from people or agents you don't trust.
• Every proposal, confirmation, automatic change, undo and cancellation is recorded in the server log with the user, the action and its outcome.

Turn actions on

1. Go to Settings → Ask CoderFlow.
2. Turn on Allow Actions.
3. Choose an Auto-Apply Limit, then click Save.

The shared catalog, including read-only lookups, uses CoderFlow's MCP tools inside the server and requires Full edition and a valid license. The external Settings → Integrations → MCP Server endpoint can remain disabled. Enabling that endpoint does not turn on Allow Actions.

With the shared catalog available, each question sends more tool definitions to the model and answers can run more lookups, even when Allow Actions is off, so usage per question rises. Sonnet, the default, and Opus choose the right tool more reliably than Haiku.

On Sonnet 5.5, an answer that follows a documentation search or lookup appears all at once rather than word by word, so in a voice conversation it is read aloud only once it is complete. Haiku streams these answers as it writes them.

Building images and running named tests

Ask can propose “Rebuild Development and show the result” or “Run the smoke test in this task.” Each run needs Confirm, even when auto-apply is enabled. The build card names the environment and explains that a build occupies the builder and can take minutes. The test card names the task and test, shows its non-secret parameters, and explains that commands run in the task container.

“Change the build setting, rebuild and show the result” uses separate cards for the saved setting and the build. Saving configuration does not queue a build. To change settings, rebuild and then start a task in one go, Ask can propose a workflow: each step still has its own card, the build waits for the saved changes, and the task waits for the build to succeed. After confirmation, the card links the build or test run it started and tracks its result. Failed builds link to their output. Ask reads that output before proposing a diagnostic rebuild. Ask cannot cancel a build.

Builds require environments:build, configured coder-setup, an available base image and no build already in progress. A CoderFlow server running as a task's App Server cannot start builds; start them on the host server. Tests require tasks:execute on the task. Ask accepts only parameters declared by the named test, up to 20 values of 1,000 characters each, 6,000 bytes of parameters and 8 KiB of input in total. Parameters marked secret and undeclared text are refused; enter credentials through the existing secure editors. Use the exact configured test name, including spaces or punctuation, up to 512 characters. Permissions and preconditions are checked again when you confirm.

Ask keeps a record of each build or test you start through it for 31 days, up to 1,000 per user. At that limit, Ask refuses new starts for you until older records expire; other users are not affected.

Final test results are kept as described in Reading task details. When runs of the same test overlap, Ask reads the most recently started run. A closed test output stream does not establish success: Ask reports an unknown result when it cannot verify that the command finished.

Interrupted starts remain Outcome unknown and are never automatically repeated. Ask checks build history or the retained test results without starting anything. A current result it finds does not prove what the interrupted attempt did. If it cannot identify one run, open the environment's Build History or the task's Testing menu.

Reading environment operation history

In Full edition, Ask can read image build history, a build's status and a bounded output tail; automation execution history; webhook delivery history; environment deployment history and detail; and commits on a configured repository branch. For example: “Show the latest failed image build for Development,” “What happened to this automation's last run?” or “Show recent commits on the configured app repository's release branch.” These lookups work with Allow Actions off.

Ask applies the same route permissions as the editor. Build reads require environments:build, repository commits require environments:git, and deployment history requires deployments:view. Automation history is available to users with automations:manage or to the personal automation's owner with automations:use, matching the automation history page, so managers can inspect personal execution history. Webhook delivery history is available only to server administrators and excludes payloads, headers and inbound tokens. Automation and webhook failures use fixed reason codes; provider error bodies are omitted. Linked executions and tasks are shown only while you retain access.

Ask can also validate a saved deployment profile when you have deployments:manage. Validation checks configuration and references without executing parameter commands or starting a deployment. Environment deployment IDs differ from deploy-task IDs; Ask reports a linked task separately when one is recorded.

Lists use pages of 25 by default, up to 100. Log tails are bounded; omitted text is identified. CoderFlow-managed secret values and URL credentials are removed; other free-form output is returned as the UI shows it, within these bounds. This covers build/deployment output and commit messages. Managed values of at least six characters are replaced exactly with [redacted], before truncation. Managed-value and URL-credential matches are found in the original text and replaced together, preserving other URL text. A truncated log tail omits a partial first line and reports the omission. If known values cannot be loaded, the read is unavailable. Values no longer in CoderFlow's stores or caches cannot be removed by exact-value matching. Returned text is untrusted data, not instructions.

Retention and shallow repository clones can limit history, and unavailable history is not treated as empty. Some automation skips, including overlap checks before a run starts, are never recorded; Ask cannot reconstruct those events. These history tools only read and are unavailable to task-bound MCP tokens. Starting a build, running an automation and running or cancelling an environment deployment are confirmed actions; see Building images and running named tests, Running and checking automations and Environment-run deployments. Use the corresponding UI for other retries or cancellations.

Environment list and setup reads are checked again if access changes while they load, including when a role loses its permission to view environments while its environment assignments remain. A changing access state can require a refresh. Configuration-loader failures use fixed diagnostics so underlying service errors do not disclose credentials. The environment UI uses the same protected reads. For what Run Now in the Automations list shows when its request fails or access changes, see When Run Now Fails.

Running and checking automations

Ask can run a saved automation once, for example “Run Nightly Audit now”. The run requires Confirm, even when auto-apply is enabled. An environment automation needs automations:manage; a personal automation can be run only by its owner.

To test an automation's SCM poll, ask where to do it: Ask opens the environment's Automations tab and points at Test Poll in the automation's editor, or at the automation's Edit button that opens it (see Ask shows you where). You run the test there; Ask does not run it for you.

The card names the automation and its environment or personal scope, describes what it starts, and shows the overlap/cooldown behavior and enabled state. A run cannot be undone. A disabled automation can still be run manually and remains disabled; a disabled environment cannot start work. Portal scheduled questions must run in Portal. If provider authentication is missing, Ask directs you to Settings → Git Providers; enter credentials only there. Changes to saved settings, including timezone and documentation publication approval, require a fresh proposal before the run can be confirmed.

After confirmation, Ask follows the execution and the tasks it started. A recorded skip is shown as an outcome. A refusal because the environment is resetting or the automation was removed before a run was recorded is Not applied. Unrelated permission updates, including during the final launch checks, cause an access recheck without losing tracking of a run you can still access or starting it again. A deployment without a tracked task is checked in execution or deployment history. These references disappear when access is revoked. If the server restarts while the run is being accepted or executed, or Ask cannot verify a run after it starts, the card shows Outcome unknown. Losing access hides the result; if access returns, an uncertain attempt remains unknown. To check, Ask looks only for manual runs you started after you confirmed; a run it finds does not prove what the interrupted attempt did, and Ask never runs the automation again to resolve uncertainty. Check the automation's History before deciding whether to propose a new run.

Server administrators can ask, “Why did this webhook delivery fail, and which automation ran?” Ask reports classified failure reasons, including task-creation and deployment-launch failures, and the execution/task links you can still access. Deleted links and other users' personal automations are unavailable. Token rotation and copying remain in the secure Webhooks editor. Launch failures retain fixed guidance: invalid settings remain validation errors, and credential failures keep their reconnect instructions. History and last-run errors do not retain provider diagnostics or filesystem paths from launch errors. The same protection applies when an IBM i run starts a documentation-refresh task or launches its later publication.

Maintaining an environment

With Allow Actions on, an authorized maintainer can ask Ask to make the common changes to an environment: its settings (such as the description, default agent and models (excluding the environment’s auto-tier map), time zone, repositories, build and runtime settings, tests and custom fields), recurring automations, templates, instruction and build files, environment skills and their files, which skills the environment uses, saved IBM i import and build profiles, deployment profiles, and memory. Ask reads the current configuration and presents the target, current values, and requested change for confirmation. The open Environment editor refreshes after the save. Existing unsaved edits must be saved or discarded before confirmation. Environment editors open in your other tabs and in other users' sessions update too; see Changes saved elsewhere.

The environment’s auto_tier_models override is also rarely used: Ask can read and explain it, but does not change it or offer a page pointer. There is no control for it in the environment editor; see Auto tier models. Settings → Models changes the separate server-wide map. A request mixing this field with allowed settings is refused as a whole; ask again for just the allowed settings.

Earlier pending cards for either retired write cannot be confirmed. They show a fixed retired notice; nothing runs. Live cards disappear on server restart.

For example:

Add an automation in development that scans dependencies for security vulnerabilities every morning at 8 AM America/New_York. Report the findings without changing code.

Ask can create the scheduled task through the automation service. It should resolve a missing time or timezone before proposing the schedule. Confirming an enabled automation activates its schedule; it does not run the task immediately.

Deployment profiles. If you can maintain deployment profiles (deployments:manage, as on the Deploy tab; the other environment changes above are not needed), Ask can create, change or delete a profile: its description, parameters, fixed environment variables, secret names and deployment script. The card shows what it will save. Ask cannot see or set the values of the profile's fixed environment variables: it keeps the saved ones, and you enter new values on the Deploy tab. Credentials are named in the profile's secrets list and must already exist on the Secrets tab with Deploy availability. Saving a profile never runs it: running a deployment is a separate card (see Environment-run deployments). Cards proposed while Ask could not change deployment profiles stay closed; ask again for a new one. A task's agent can make the same changes in its own environment; see Creating and editing profiles with an agent.

What Ask only reads. Less common changes are made in the CoderFlow UI. Ask can read the current state, explain what to change and open the page for you, but it does not propose these changes:

Change	Where to make it
Create, clone, import or delete an environment	New Environment, Clone Environment…, Import Environment… or Delete Environment in the actions menu on the Environments page
Rename an environment	The rename (pencil) button next to the environment name on the Environments page
Enable, disable or draft an environment	Status under Environment Information on the environment's Overview tab
Webhooks	The Webhooks list on the environment's Automations tab
Connections	The environment's Connections tab; Ask can open a saved connection's dialog for you
MCP servers	MCP Servers on the environment's Overview tab
Task orchestration (CoderFlow MCP for tasks)	Task orchestration on the environment's Overview tab
Portal settings and the Portal application catalog	The environment's Portal tab
Codex speed policy	Codex speed modes on the environment's Overview tab
Adding, changing or deleting secrets	The environment's Secrets tab
Installing or updating skills	The Skills page (see Installing and updating skills)
Publishing shared skill files	Commit & Push on the Skills page

If a change you ask for needs a secret the environment does not have yet, add it on the Secrets tab first, then ask again. Ask never asks for a secret value and never adds, changes or deletes a secret.

The MCP Server guide lists the resources external MCP clients can edit and their permission requirements; Ask edits only the common ones above. Ask hides structured credential fields by their schema. It also hides every literal value in headers and environment-variable maps, regardless of the key name. Use the secure editor to edit those maps, including non-secret values; supported secret references can still be used through Ask. URL credentials and external URL query values are hidden; Git SSH account usernames remain visible. Harmless QA URL templates remain editable; templates containing URL credentials or literal query/fragment values are hidden in full and require the secure editor. Same-origin launch paths, including queries such as /portal/?environment=dev, stay visible and editable.

User-authored files, scripts, commands, template/skill bodies and other plain text are not scanned for secrets. Credentials pasted into that content can reach Ask. Resource revisions detect changes to hidden snapshot values and stay stable across restarts of the same server installation. The server keeps a private revision key in its data directory; if it cannot safely read that key, resource reads and changes are unavailable until the key is restored and the server restarted. Saving configuration is separate from building, deploying, or publishing it. Environment changes always require confirmation, even when the conversation can automatically apply task actions. Some of them can be undone for 24 hours; see Undoing environment and automation changes.

Connection and Portal readiness

Ask can test a saved SQL or SSH connection. The test uses the credentials already saved on the server, contacts the configured system and always needs your confirmation.

For an IBM i connection's special authority, RAS or Profound UI checks, Ask opens the connection's dialog and points at Test connection, which checks each service the connection uses; for its library lists, at Manage lists… under Library Lists, where a list is checked when you change it. You run these checks yourself (see Ask shows you where). A test needs environments:manage for the environment; the connection's features are checked again when you confirm. The card shows the connection ID separately from the readiness job ID, and reading a job's status needs both. A test does not create an environment deployment or a deploy task.

Passwords, private keys, tokens and passphrases stay in the existing connection dialog; Ask never accepts them in the conversation. Ask can open that exact saved connection for secure entry, Bridge provisioning, TLS trust changes, key installation or Portal trust setup. Saving there does not confirm an operation in Ask: ask again for a fresh check. Stored credentials are never returned to Ask or the browser.

If a test cannot be proposed, Ask explains whether stored credentials are missing or the connection needs configuration. Credentials saved for a host or user the connection no longer has (for example after environment.json was edited through the setup repository) count as missing: they are never sent to the changed target. Missing credentials direct you to the connection dialog. If readiness checks are busy, Ask reports that no check started; wait, then ask for a fresh check. Confirming the refused card again does not retry it.

Ask can read readiness jobs, cancel a saved-connection test it is running, or inspect recorded trust, application hosting and catalog counts. Catalog saved, trust installed, service reachable and hosting ready are different results; a completed check is evidence only for the service it reports. PUI readiness does not verify a user's 5250 sign-on. Cancellation preserves earlier setup changes and reports the job's actual state. If the job already completed, failed or was cancelled by another reader, Ask says it already finished and nothing was cancelled.

Portal launch trust setup happens in the guided Launch trust dialog (see IBM i Portal Applications). Ask does not plan, close or cancel it: it opens the connection's dialog and points at Set up launch trust…, or at Review setup or Cancel setup when that dialog is open.

Readiness jobs are held in the server's memory. If a server restart loses a job, the card shows Outcome unknown; Ask reads current status and never repeats an interrupted operation automatically. When a diagnostic supplies a specific failure category, Ask distinguishes unreachable systems, authentication failures and missing authority; other failures remain generic. Remote error text and credential values do not enter the conversation or Recent actions.

Environment-run deployments

Ask can run an environment deployment or cancel a running environment deployment. These are separate from deploy tasks: an environment run has a deployment ID; a deploy task, like one started from the dashboard Deploy menu, has a task ID. Ask keeps both paths and their histories separate and does not substitute one for the other. IBM i deployment profiles cannot be run this way; run them from the dashboard Deploy menu so you can review the object selection. See Deployment Profiles for how profiles are configured.

Every environment run needs Confirm, including a dry run. Review the named environment and profile, repository branches, non-secret parameters and whether it is Dry run (validates without running the deployment script) or Real deployment. A deployment changes external systems and is never retried automatically. Supply declared non-secret parameters only; secrets come from the environment, so configure them in its secure editor. Undeclared, secret-typed or oversized inputs are refused: each branch or parameter value is at most 200 characters, with at most 20 of each, and the resolved parameters (including defaults) and the branch selections must each fit in 1,000 characters. Larger requests must use the environment's Deploy tab. Like a background task, a real deployment needs a server callback URL for Git credentials (see Set the Public URL); if the server has none, Ask refuses before starting.

Parameter defaults and repository branches shown on the card are saved with the proposal, including across a restart. A later default change cannot silently change the deployment. If the saved profile no longer accepts the reviewed values, adds effective parameters, or the environment gains a repository, Ask requires a fresh proposal. Select a branch explicitly if a repository has no configured default. Changing a repository's URL, path or provider also requires a fresh proposal.

The card follows the environment deployment's recorded status: running, completed, failed or cancelled. If the server restarts during execution, the attempt stays Outcome unknown. Ask then reads only retained history for this profile and your runs after you confirmed. A matching record is an observation, not proof the interrupted attempt ran. If none is found, use Open deployment history; Ask never starts a second deployment to recover the first.

Cancelling requires a separate confirmed card. Ask polls the actual state and can read the bounded, redacted deployment output to explain what already ran. Cancellation does not undo that work and provides no compensation or rollback. A deployment that already finished is left alone.

Confirming a run needs deployments:execute, the same as running the profile from the Deploy tab. Cancelling, and seeing a started run's card, result and Recent actions entry, need both deployments:execute and deployments:view. Following its status and reading deployment history need deployments:view. An unavailable card cannot be confirmed through the API. After an environment is renamed, finding a deployment's status under the new name can take up to 30 seconds. Access is checked again on each read. These tools are unavailable to task tokens, including tokens allowed to start deploy tasks.

Readiness and environment-deployment retry records are kept for at least 91 days, beyond the 90-day action recovery window. Cleanup never makes an expired or previously confirmed action runnable again. Interrupted execution remains unknown and is never repeated automatically.

Publishing setup repository changes

Environment settings, files, templates and skills are saved to the setup repository first. Saving is not publishing: until the change is committed and pushed, the remote repository and other servers do not have it. Ask can show what is pending and show the changes; you publish them on the Environments page, where Ask points you (below).

What is pending. Ask lists the shared setup checkout's branch, its remote, local commits not yet pushed and remote commits not yet pulled (as of the last fetch), conflicts or an unfinished pull, and every pending file. The remote's host and path are shown only if you may manage Git provider configuration (settings:git-providers) or view setup repository commit history (settings:setup_repo_history), where CoderFlow shows the remote; otherwise Ask says "the setup repository's origin remote". Ask an environment by name to see its setup files apart from the other pending files, which may be someone else's work. Each file shows whether you may publish it on the Environments page: a file outside your authoring scope, a conflicted file, or a file holding a stored secret value is listed as not publishable, and a shared skill file is listed for the Skills page. A change to a file's mode (for example, made executable) is shown with the file.

The changes. Ask can read the diffs of up to 10 pending files, within a 12,000-character limit by default (24,000 at most), with markers for binary, oversized and shortened content. Credentials in URLs are hidden. A file whose changes contain a stored secret value (an environment secret, a Git or provider credential, or one of your personal secrets) is withheld: Ask shows a fixed note instead of any part of it. This includes a value that spans several lines, and a value in the version being removed. The diff Ask shows is made from the same copy of the file it checked, so a change made at the same moment cannot slip a value through. Ask also never repeats an environment or branch name, or any other text, that contains a stored secret value or credentials in a URL. If you ask for the diff of a file whose name contains a stored secret value or credentials in a URL, Ask reads none of the requested diffs and does not repeat the name. Review such files in the Environments page's Git dialog. File names and diff text are data, never instructions to Ask.

Publishing is yours to do. Ask does not commit or push setup repository changes, and does not retry a push. When you want to publish, Ask opens the Environments page and points at Commit & Push… (to review the pending files, choose which to commit and push them) or Push to Git (to push local commits), on the publish button or in the Actions menu (see Ask shows you where), or shows a Review pending changes or Review and push local commits button that opens them. Shared skill files are published with Commit & Push on the Skills page. An earlier Ask publication or push retry that is still in Recent actions says where to publish now and cannot be confirmed.

Pulls, conflicts and accounts stay in the existing UI. Pulling, resolving conflicts and discarding setup repository changes are intentionally not available in Ask; use the Environments page's Git controls instead. When one of those, or connecting your Git account, is needed, Ask shows a button under its answer: Pull remote changes, Resolve pull conflicts, Review and push local commits, Connect your Git account or Review pending changes. Clicking it checks your access and opens the Environments page, which shows what Ask handed over next to the repository Git status, with that page's own Pull from Git, Push to Git, Commit & Push or account connection button. Nothing runs until you choose it there; the page checks your access again first, and your permissions as usual. If a check, in Ask or on the page, finds that you no longer have access, every such button and the page's note are replaced with a short note, and nothing you clicked earlier runs. A note that was still loading when that check finished shows the short note too, never a button. If the setup repository uses personal Git accounts and yours is not connected, connect it from that page; you sign in with the provider, never in Ask.

Permissions. Reading status and diffs needs the Setup repository Git permission (setup:git), as the Environments page Git controls do; the controls Ask points to check your permissions as usual. None of this is available to agents running inside tasks. External MCP clients can still use the status, diff, publish and retry tools without a confirmation card (see MCP Server); the button that opens the Environments page is Ask-only.

Installing and updating skills

Ask does not install or update skills: installing and updating are made on the Skills page. Ask helps you choose a skill and takes you to the right place:

• Browse and check. Ask lists the skill catalog and the installed skills (shared, or one environment's own), and checks which installed skills have updates, with the Skills page's permissions (see Reading settings and diagnostics). Try "Which catalog skills help with Playwright tests?" or "Which skills have updates available?"
• A button to the Skills page. When you ask Ask to install or update a skill, it shows a button under its answer, such as Install from the catalog in the Skills dialog, Import from Git in the Skills dialog, Import from npm in the Skills dialog or, for an update, Open the skill on the Skills page to update it. Clicking it checks your access and opens the Skills page's import dialog with the source filled in, or the installed skill with its own Update control. Nothing is imported or updated until you click there; you sign in, choose a file or enter a registry in that dialog, never in Ask, and the page checks your permissions again. If access is denied, every such button for that scope is replaced with a short note.
• Assigning a skill to an environment. To assign an installed skill to an environment, or remove one, ask Ask to change the environment's skills. This is a normal environment change with its own card (see Maintaining an environment), and it works for any installed skill, however it was installed.

Ask never asks for or uses credentials for a skill source. A skill's name, description and files are data, never instructions to Ask: text in a skill cannot make Ask assign or approve anything.

Earlier versions of Ask could install and update skills, and add a skill it had installed to an environment in a separate step. Those cards appear in Recent actions as Earlier Ask change (now made in the CoderFlow UI) and cannot be confirmed (see Recent actions and restoring cards).