aaif-goose/goose · error

Could not retrieve sub-recipe '{}': {}

Error message

Could not retrieve sub-recipe '{}': {}

What it means

When extra sub-recipes are passed on the CLI, extract_recipe_info_from_cli resolves each one via load_recipe_file (crates/goose-cli/src/recipes/extract_from_cli.rs:28-46). If that lookup fails (file not found, unreadable, or the name cannot be resolved through the configured recipe sources), the operation aborts with this error naming the offending sub-recipe and the underlying cause.

Source

Thrown at crates/goose-cli/src/recipes/extract_from_cli.rs:42

    if !additional_sub_recipes.is_empty() {
        let mut all_sub_recipes = recipe.sub_recipes.clone().unwrap_or_default();
        for sub_recipe_name in additional_sub_recipes {
            match load_recipe_file(&sub_recipe_name) {
                Ok(recipe_file) => {
                    let name = extract_recipe_name(&sub_recipe_name);
                    let recipe_file_path = recipe_file.file_path;
                    let additional_sub_recipe = SubRecipe {
                        path: recipe_file_path.to_string_lossy().to_string(),
                        name,
                        values: None,
                        sequential_when_repeated: true,
                        description: None,
                    };
                    all_sub_recipes.push(additional_sub_recipe);
                }
                Err(e) => {
                    return Err(anyhow!(
                        "Could not retrieve sub-recipe '{}': {}",
                        sub_recipe_name,
                        e
                    ));
                }
            }
        }
        recipe.sub_recipes = Some(all_sub_recipes);
    }

    let input_config = InputConfig {
        contents: recipe.prompt.clone().filter(|s| !s.trim().is_empty()),
        additional_system_prompt: recipe.instructions.clone(),
    };

    Ok((input_config, recipe))
}

View on GitHub (pinned to 3810898a74)

Solutions

1. Verify the sub-recipe identifier exactly matches a local file path or a known recipe name; fix typos and run from the directory that makes relative paths valid
2. If it should come from GitHub, confirm GOOSE_RECIPE_GITHUB_REPO is set to owner/repo and that the folder contains a recipe.yaml (or another supported extension)
3. Read the chained `: {}` cause — it is the underlying load_recipe_file error and states precisely why the lookup failed

// Before passing sub-recipes, confirm each resolves to a readable file
fn sub_recipe_paths_valid(names: &[String]) -> anyhow::Result<()> {
    for name in names {
        if !std::path::Path::new(name).exists() {
            anyhow::bail!("sub-recipe '{name}' does not exist as a local file; \n                              check GOOSE_RECIPE_GITHUB_REPO for remote resolution");
        }
    }
    Ok(())
}

// Rust: match on the load and report name + cause together
if let Err(e) = load_recipe_file(&sub_recipe_name) {
    eprintln!("sub-recipe '{sub_recipe_name}' failed to load: {e:#}");
    continue; // or abort, depending on policy
}

When it happens

Trigger: Invoking a recipe with additional sub-recipes (`goose run --recipe ... --with-subrecipe <name>` style flows) where the sub-recipe identifier is neither an existing local file path nor discoverable in the configured recipe locations (including GOOSE_RECIPE_GITHUB_REPO when set), or the file exists but is unreadable.

Common situations: Typo in the sub-recipe name, passing a relative path from the wrong working directory, a sub-recipe folder in the GitHub recipe repo lacking a recipe.{ext} file, or GOOSE_RECIPE_GITHUB_REPO unset while expecting remote resolution.

Related errors

• Unknown error occurred
• No recipe file found in {} (looked for extensions: {:?})
• Invalid repository name format
• Failed to access directory: {}
• Failed to fetch OIDC config: ${configResp.status}

AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16). Data as JSON: /api/errors/4f4aaf8282f74f74. Report an issue: GitHub.