Troubleshooting

Nothing here matches - where are the logs?
My file shows up but has no tasks
$env:NAME comes back empty
A task silently does nothing
The run stopped and half the graph says Skipped
A task failed before anything ran
An ai@1 arg did nothing at all
The agent says it has no MCP tools
An ai@1 task sits at Running and never finishes

Nothing here matches - where are the logs?

The Command Palette has Local Workflows: Show Logs. It opens the extension’s own output channel, where activation, the run database’s location, and anything that failed quietly are written with a timestamp and a level.

It is the right place to start for anything this page does not cover, and the right thing to attach when reporting a problem - a toast is gone the moment it is dismissed and carries no detail.

My file shows up but has no tasks

Check the top-level key. It is tasks:, not tasks:. A file whose top-level key is anything else parses successfully into zero tasks and appears empty, because there is nothing there to reject.

tasks:            # not `tasks:`
  hello: echo Hello World

`$env:NAME` comes back empty

The task ran in the OS default shell — cmd on Windows, bash elsewhere — not PowerShell. A task gets pwsh only when it asks:

  build:
    shell: pwsh
    run: echo "Building in $env:BUILD_CONFIGURATION..."

A task silently does nothing

An unquoted YAML scalar containing ": " parses as a nested mapping, and the task’s run: quietly becomes something else. Quote the whole thing:

    run: echo "exported = $env:ARTIFACT_NAME - env read the var"

The run stopped and half the graph says Skipped

A failed task skips everything that needs: it, transitively. Unrelated branches keep going. Open the failed node’s log in the side panel — the status on the parent tells you nothing that the failing task’s own status does not tell you better.

A task failed before anything ran

Validation runs before the first command. An unregistered uses:, a missing required arg, an arg the plugin does not accept, or a ${{ vars.X }} declared nowhere all stop the run up front, with the message on the task that has it. Click the task in the run panel to read it, or hover it on the map for the same thing.

That is deliberate: a pipeline that gets three tasks in before discovering a typo has already changed things on your machine.

ai@1 is the exception to “an arg the plugin does not accept”. It hands anything it does not declare to the runtime, so a misspelled arg there is never reported — see below.

An `ai@1` arg did nothing at all

Nothing validates it, and nothing will. ai@1 passes every arg it does not declare to the agent runtime under that name, because the runtime’s own session options outnumber and outpace anything this extension could restate. An arg the runtime does not recognise either is simply dropped by it.

So availableTools: works and avilableTools: is silence. Check the spelling against the runtime’s own option names, not against the ai@1 arg table — that table is only the handful the engine uses.

The agent says it has no MCP tools

Name the server in the prompt. This is the common one. “Use the available MCP server” is not something the agent can resolve; use the ado MCP server is.

Check where the server is declared. Two places count, and the editor’s own mcp.json is neither of them:

ai.mcpServers in .local-workflows/settings.json — the workspace’s or your profile’s. The sidebar’s MCP Servers view lists exactly what these two files declare, so if it is not in that list, no task will see it.
The Copilot CLI’s own discovery files — ~/.copilot/mcp-config.json, .mcp.json, .github/mcp.json.

A server that answers in the editor’s chat panel but is in none of those is not bridged across and does not exist for an ai@1 task. Full reference: settings.json.

Check the server is not disabled. A ticked-off checkbox in the MCP view writes "disabled": true into the declaring file, and a disabled server is skipped silently.

Check allowedTools. Present, it is an allowlist — a tool not named there is not offered. deniedTools wins over it.

A mcpServers: block in the task’s args is not supported and is removed before the session opens. The Session options: line in the task log shows the config exactly as sent.

Check availableTools: against wire names. An MCP tool’s wire name is <serverKey>-<toolName>: a server declared as ado surfaces wit_work_item as ado-wit_work_item. An allowlist entry with the bare name matches nothing — the server connects, its tools are filtered out, and the agent reports it has no ADO tools while the log shows the server initialising happily. Tool names also drift between server versions; pin the server package’s version in your MCP config so they cannot.

A remote server that signs in over OAuth may still fail. Nothing is watching the run to complete a sign-in, so a server that has never been authorised on this machine cannot be authorised by a task. A launched server with a token in its env: works unattended and is the shape to reach for.

An `ai@1` task sits at Running and never finishes

It is probably waiting on a permission. Nothing approves on your behalf, so a tool the agent needs permission for leaves the request pending in the conversation.

Select the task and open the session from the log header — the request is there, in context, and answering it lets the turn carry on. The run panel does not yet mark which task is waiting, so a task that has been at Running with no new output for a while is the one to open.