Skip to content

v2026.09.1

Choose a tag to compare

View all tags
@github-actions github-actions released this 23 Sep 23:38
v2026.09.1
3ca341a
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

What reached AI Workflow users, collected on 2026-09-23.

Dashboard

Ten changes in this area.

  • The Integrations connection page now names enabled workflows and counts runs in flight before disconnecting or applying a connection change that would stop them; if the impact cannot be read, the confirmation says it is unknown instead of showing zero. (in #510 by @outof-place)
  • The Integrations screens say what is true for a provider nobody connected: no source "in use" and no switch saying workflows may use it. Without an encryption key for stored secrets, the page explains the key, links to how to set it, and turns saving off where it could only fail. Secret fields now show what they are for. (in #511 by @outof-place)
  • Dashboard times are shown in UTC with the zone named, the same on every page. The setup overview says when its health scan was taken and flags a stale one; an integration that reads Connected says so when the latest health scan found it down, and turning off a tracing integration says runs go on untraced rather than stopping. Sign out is reachable on a phone. (in #511 by @outof-place)
  • The Integrations screens no longer point at a switch that is not shown, and an integration whose Test passed after the last health scan no longer carries that scan's warning. Times end in a fixed "UTC", and the setup overview marks its health scan stale as soon as it is, even on a page left open. (in #513 by @outof-place)
  • The dashboard Integrations screens show each integration's own icon, and every card says at a glance whether an integration is not set up, incomplete, switched off, failing, or connected but never tested. (in #524 by @outof-place)
  • An integration's connection screen says first where its values come from, and a value read from the deployment's environment is shown as set and hidden, naming its variable, instead of as an empty field. A switched-off or failing integration keeps its place in the sidebar, marked Off or Failing. (in #524 by @outof-place)
  • The workflow editor now says why a Deploy did not go through: the first reason, in the block's name, with a link to that block and to the full list of issues. A Deploy button that cannot be pressed says why on hover. (in #521 by @outof-place)
  • In the workflow editor, the notice about steps that cannot run sits above the canvas instead of covering its blocks, the toolbar wraps on narrow screens, and the source scope bar shows "Loading…" until providers are known. (in #521 by @outof-place)
  • The workflow editor asks "Discard unsaved changes?" before a sidebar link or the browser's Back leaves an unsaved graph, keeps the open workflow in the address so a refresh or a shared link reopens it, gives a pasted block its own name, and on a phone puts Undo, Redo, Deploy and Save draft in one row with the rest under More. (in #530 by @outof-place)
  • The Overview and the Runs page count a window's runs the same way, name older runs still waiting for input apart, show run ages in hours and days, and say which runs hold the occupied slots; a run's Logs tab shows each log event's fields as readable text. (in #530 by @outof-place)

Runs and workflows

13 changes in this area.

  • A harness profile can pick a Claude model again: the Model list offers what the Claude CLI reports (default, opus[1m], sonnet, haiku), and publishing a profile on one of them is accepted. The built-in Claude profile no longer calls its model unavailable; it says the built-in profile sets it. (in #513 by @outof-place)
  • A workflow run started by a pull request now reports a failure on that pull request, naming the workflow, and leaves its linked ticket where it is on the board; the ticket comment names the pull request and the workflow. (in #512 by @outof-place)
  • Runs are named after the workflow definition and version they ran (for example "Autofix PR checks v3") in runs.stats, runs.get, tickets.list_runs and on the ticket page, and a manual dispatch preview says when a held reservation belongs to a run that already finished. (in #512 by @outof-place)
  • MCP tickets.transition now accepts a target named after the status it lands on, not only the transition's own label, so it matches every status name the tool's own error message offers. (in #522 by @outof-place)
  • Run logs keep a cost value's decimal digits as they are instead of masking them as a payment card. (in #522 by @outof-place)
  • The runs.stats cost breakdown now lists spend by each workflow definition's name instead of combining every ticket workflow into one total. (in #522 by @outof-place)
  • Pre-PR checks and the Run scripts block now run a repository's script groups whatever letter case its catalog entry uses, since GitHub and GitLab treat Acme/api and acme/api as one repository. (in #526 by @outof-place)
  • When the pre-PR checks pass over a repository, the run summary names it and says why: the run did not change it, or it is not in the run's workspace. (in #526 by @outof-place)
  • A ticket moved back to start after its pull request was closed and its branch deleted now starts again from the repository's default branch, and the run posts a ticket comment naming the deleted branch. (in #523 by @outof-place)
  • When the sandbox service refuses to create a workspace, the run's failure message names the repository, the branch and the service's reason, with what to check next. (in #523 by @outof-place)
  • When an AI provider account refuses a run, the Jira comment, the Slack message, the run's failure reason and runs.diagnose now name the provider (Anthropic or OpenAI), say what happened to the account (no credit, a spend or plan limit, a rejected key) and that an admin of that account fixes it; runs.diagnose files these under provider_account. (in #529 by @outof-place)
  • When someone moves a ticket out of the trigger column, its run and the step it was on close at once, the ticket gets one short comment saying when the run stopped and how to start again, and runs.diagnose answers ticket_left_trigger_column with the time. Clarification answers given through MCP are signed on the ticket with the person's name or email and the client's registered name, and plan comments name ticket attachments by their file name. (in #529 by @outof-place)
  • A ticket's working notebook is now kept when the agent writes it from inside a repository checkout, and a run that leaves no notebook logs a warning naming every place it looked. (in #520 by @outof-place)

Integrations

28 changes in this area.

  • The cockpit's activity drawer now shows an honest "Nothing here yet" state instead of sample events from providers nothing is connected to. (in #528 by @outof-place)
  • The Arthur Engine is an integration, with its card on the Integrations page, its checks on System health, and its own sidebar section holding Evals once it is connected; old Evals links land there. Deployments that set GENAI_ENGINE_API_KEY and GENAI_ENGINE_TRACE_ENDPOINT keep working unchanged, and the key reaches only the tracer inside an agent sandbox. (in #510 by @outof-place)
  • The Prompt injection check reports a screening result or stops the run with the reason. With nothing bound it screens the ticket's description and comments, and publishing is refused when a workflow started by a pull request or a schedule leaves the content unbound, or when no Branch straight after the check decides on its status. (in #510 by @outof-place)
  • GitHub is an integration: connect it on the Integrations page or keep the environment variables you already have, and the App keeps posting to the same webhook URL. The Connection form takes the App's private key as a pasted .pem file or as base64, and a deployment with only part of its GitHub values set starts and names the missing one on the Integrations page. (in #510 by @outof-place)
  • The GitHub card on the Integrations page checks the App itself: whether GitHub accepts the key, whether the installation still exists and grants repositories, whether the App subscribes to the events workflows need, and what GitHub's delivery log says about the last delivery. (in #510 by @outof-place)
  • GitLab is an integration: connect it on the Integrations page or keep the environment variables you already have, and merge requests, comments and failed pipelines keep arriving at the same webhook URL. Each repository names the provider that serves it, so a deployment can run GitHub, GitLab or both, and VCS_KIND can be removed. (in #510 by @outof-place)
  • Disconnecting a version control provider on the Integrations page names the repositories it affects, beside the workflows and runs. A run that uses repositories on two providers depends on each one separately, so changing one mid-run stops only the work that needed it, and says which. (in #510 by @outof-place)
  • Developers can add an integration of their own: pnpm run new:integration creates a package that passes every check before it is edited, and the guide in docs/architecture/integrations.md takes it from there to a connected card on the Integrations page. (in #510 by @outof-place)
  • The sidebar separates the product from its integrations: the usual groups, then Integrations with one entry for each connected, switched-on integration, opening its own area with tabs for its screens and for Connection. Groups fold away when you want the room. (in #510 by @outof-place)
  • System health and Users are tabs under Settings, and their old links keep working. (in #510 by @outof-place)
  • Saving or deploying a workflow checks the Investigate block's query template the way the connected issue tracker reads it: Jira accepts values in single or double quotes, and a new template Jira would skip, such as one with an unclosed quote or a stray parenthesis, is refused with the reason. (in #510 by @outof-place)
  • A template that already runs keeps working and shows as a notice in the workflow editor, which does not block deploying, and an Investigate run that searched without its template says so in the block's theory. (in #510 by @outof-place)
  • Jira is an integration: connect it on the Integrations page or keep the environment variables you already have, under the same names, and Jira keeps calling the same URL. The Jira card checks that the project key names a project this account can see, and that a Jira webhook points at this deployment, is switched on and sends issue updates. (in #510 by @outof-place)
  • A deployment can run with no issue tracker at all, and anything that needs a ticket says so where you are. The Investigate block speaks of an issue tracker and chat rather than Jira and Slack, still hands a JQL template you wrote to Jira, and saved definitions keep drawing and running as they did. (in #510 by @outof-place)
  • Mem0 can hold this deployment's memory: connect it with an API key on the Integrations page, where Test names the Mem0 organization and project the key writes into, and what runs learn, their notebooks and the memory screen's documents then live in that project. Disabling it brings back the built-in memory as it was, and nothing is copied either way. (in #510 by @outof-place)
  • Memory is a capability, and the built-in store is its provider until a memory engine is connected in its place: a deployment that connects nothing keeps everything the store holds. A run that could not reach memory says so on the run itself, for the workspace it started in, the facts it could not seed and the prompt it went in with. (in #510 by @outof-place)
  • The Memory screen says when a provider is away, when it cannot list what it holds, and when a listing is partial. Three MCP tools, memory.list, memory.get and memory.forget, offer the screen's three actions under the same roles the dashboard requires for a delete. (in #510 by @outof-place)
  • Who may run the /ai-workflow Slack command is now a setting: change it on the dashboard Settings page (Integrations) or with the MCP settings.set tool, and the next command uses it without a redeploy. SLACK_ALLOWED_USER_IDS is still read until a value is saved, and changing the list never interrupts a run that is posting to Slack. Each user id is its own entry: an entry that is blank or holds a comma is refused, since it would lock everyone out or let everyone in. (in #510 by @outof-place)
  • The /ai-workflow Slack command answers on a deployment that set only SLACK_SIGNING_SECRET. When a command cannot be completed, only the person who typed it sees the answer, with a reference an admin can look up in the worker's log, and Slack messages about a GitLab merge request call it an MR. (in #510 by @outof-place)
  • Slack is an integration: connect it on the Integrations page or keep the CHAT_SDK_* and SLACK_* variables you already have, and /ai-workflow answers at the same address in the same threads. "Send Slack message" is now "Send message" and works through whichever messaging integration is connected; saved workflows keep running and open as the new block. (in #510 by @outof-place)
  • Send message reports success only for a message that arrived, and otherwise reports skipped with the reason, which a workflow can branch on. A deployment with no messaging integration still runs its workflows, and a block that needs one names what to connect before any work starts. (in #510 by @outof-place)
  • Planning and implementation agents now see a Jira ticket's parent, its subtasks in their ranked order, and its links ("blocks", "relates to") with each one's key, status and title, in the prompt's runtime data and in the run briefing. Repository discovery reads the same list, so a parent whose subtasks name their files points discovery at the right repository. (in #525 by @outof-place)
  • Acceptance criteria are now read from a description that labels them "Acceptance:" or "AC:", as well as "Acceptance criteria". (in #525 by @outof-place)
  • The webhook delivery log at GitHub and GitLab now tells a queued delivery from a dropped one. A review or failed check that arrives while a run is already working on the pull request, or while the deployment is at its run limit, answers queued and starts once there is room. One refused by the trigger's start budget or by the pull request's fix-attempt cap answers ignored with rate_limited or autofix_cap_reached, and no run follows it. (in #510 by @outof-place)
  • A commented review that cannot start a run because this deployment does not know its own automation account answers ignored_bot_login_unknown in the provider's delivery log. Filling in Bot username on the provider's integration is what lets commented reviews start runs. (in #510 by @outof-place)
  • When the Legacy default project setting (GITLAB_PROJECT_ID) keeps a GitLab delivery out, GitLab's delivery log says so and names the project the setting allows, so a project enabled on the Repositories page and still refused shows why. (in #510 by @outof-place)
  • A pull request that was deleted, or that this deployment's connection may not see, is closed in the delivery log as ignored_pull_request_unreadable. A credential the provider refuses as a whole (a token it stopped accepting, a GitLab token without the read scope, a GitHub App without the pull request permission) is the connection's problem, not the pull request's: the delivery answers ignored with vcs_credential_refused and a diagnostic id, the Webhook delivery row on the Integrations page turns red, and GitLab keeps the webhook switched on, so deliveries are acted on again as soon as the credential is repaired (those answered in the meantime are not replayed). A review or failed check already queued waits for that repair and then starts, and a run whose pull request could not be read at that moment stands down instead of showing as failed. Running a workflow by hand on a pull request that does not exist or cannot be read says so, and a provider that cannot read pull requests at all says that, instead of calling either an outage. (in #510 by @outof-place)
  • The Webhook delivery row on the Integrations page, and the email delivery-status row, count only the requests this deployment received, told apart by its public address, so a demo and a production deployment that share one database each see their own. Requests counted before this release are not carried over: right after the upgrade every Webhook delivery row reads "No webhook request has reached this worker in the last 7 days" until its provider sends the next request. For a quiet Slack command or Jira project that can take days; any delivery, such as a test delivery from the provider's webhook settings where it offers one, turns the row Live at once. (in #510 by @outof-place)

Setup and operations

Two changes in this area.

  • The dashboard Settings page tells you when someone else changed a setting after you opened the page: your edit stays on screen next to their value, and you choose to store yours over it or take theirs. MCP settings.set and settings.reset accept the same expectedVersion. (in #531 by @outof-place)
  • Owners can remove a stored setting from the Settings page with "Remove stored value", after a confirmation that names the value that takes over and where it comes from, and the settings history names who made each change. (in #531 by @outof-place)

Full Changelog: https://github.com/Blazity/ai-workflow/commits/v2026.09.1

Assets 2
Loading