Zed cannot determine how to run this debug scenario. `build`

Error message

Zed cannot determine how to run this debug scenario. `build` field was not provided and Debug Adapter won't accept provided configuration because: {e}

What it means

Terminal fallback diagnostic: when the scenario's config is invalid (`config_is_valid == false`), no `build`/locator output exists to repair it, and the adapter's `request_kind()` rejected the config with error `e`, Zed reports that it has no way to run the scenario and embeds the adapter's rejection reason (running.rs:1270). `e` names the concrete missing/invalid field.

Source

Thrown at crates/debugger_ui/src/session/running.rs:1270

                    label: label.clone(),
                    adapter: adapter.clone(),
                    request,
                    stop_on_entry: None,
                };

                let scenario = dap_registry
                    .adapter(&adapter)
                    .with_context(|| anyhow!("{adapter}: is not a valid adapter name"))?.config_from_zed_format(zed_config)
                    .await?;
                config = scenario.config;
                util::merge_non_null_json_value_into(extra_config, &mut config);

                Self::substitute_variables_in_config(&mut config, &task_context);
            } else {
                let Err(e) = request_type else {
                    unreachable!();
                };
                anyhow::bail!("Zed cannot determine how to run this debug scenario. `build` field was not provided and Debug Adapter won't accept provided configuration because: {e}");
            };

            Ok(DebugTaskDefinition {
                label,
                adapter: DebugAdapterName(adapter),
                config,
                tcp_connection,
            })
        })
    }

    fn handle_run_in_terminal(
        &self,
        request: &RunInTerminalRequestArguments,
        mut sender: mpsc::Sender<Result<u32>>,
        window: &mut Window,
        cx: &mut Context<Self>,
    ) -> Task<Result<()>> {

View on GitHub (pinned to f4178619ac)

Solutions

Read the `{e}` suffix — it is the adapter's own validation error naming the missing/invalid field; fix that field first.
Add the required fields (Python: `request` + `program`; Node: `program`; etc.) to `config`.
Alternatively add a `build` task to the scenario so Zed can derive a locator even when the raw config is incomplete.
Validate the config against the adapter's documented schema before saving.

Example fix

// before
{
  "adapter": "Python",
  "label": "Debug main",
  "config": { "request": "launch" }
}

// after
{
  "adapter": "Python",
  "label": "Debug main",
  "config": { "request": "launch", "program": "$ZED_FILE", "console": "integratedTerminal" }
}

Defensive patterns

Strategy: validation

Validate before calling

// validate adapter-required fields before the session starts
let request = config.get("request").and_then(|v| v.as_str());
if !matches!(request, Some("launch") | Some("attach")) {
    return Err(anyhow!("config must set request to launch or attach"));
}
if adapter_needs_program(&adapter) && config.get("program").is_none() {
    return Err(anyhow!("config for {adapter} requires `program`"));
}

Type guard

fn is_minimally_valid_debug_config(adapter: &str, config: &serde_json::Value) -> bool {
    let request_ok = config
        .get("request")
        .and_then(|v| v.as_str())
        .is_some_and(|r| r == "launch" || r == "attach");
    let program_ok = !adapter_requires_program(adapter) || config.get("program").is_some();
    request_ok && program_ok
}

Try / catch

Run adapter `request_kind` eagerly at config-edit time, catch its Err, and display that reason inline — this is exactly the `{e}` the runtime error embeds, surfaced before launch.

Prevention

Start from a working example config per adapter and change one field at a time.
Prefer adding a `build` task when the config cannot be fully valid on its own.
Validate configs in CI with the same adapter schema checks.

When it happens

Trigger: E.g. a Python config missing `program` or with a bad `request` value, a Node config missing `program`, wrong-typed fields (port as string), or unknown keys the adapter rejects — combined with no `build` field that could supply a locator instead.

Common situations: Hand-written debug.json missing required fields; pasting VS Code launch.json sections that use keys the adapter does not accept; typos in `request` (`"lauch"`); migrating configs between Zed versions where adapter requirements tightened.

Related errors

AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/5bf04847a6e0e73d. Report an issue: GitHub.