collaboration mode default template must render: {err}

Error message

collaboration mode default template must render: {err}

What it means

The default collaboration-mode template parsed, but rendering it with the single supplied key (KNOWN_MODE_NAMES) failed, panicking inside default_mode_instructions(). In practice this means the template references a placeholder other than KNOWN_MODE_NAMES, or syntax that only fails at substitution time. Like the parse panic, both inputs are compile-time constants (the DEFAULT template and TUI_VISIBLE_COLLABORATION_MODES), so hitting this means a crate invariant was broken by a template edit, not by runtime data.

Source

Thrown at codex-rs/models-manager/src/collaboration_mode_presets.rs:44

        developer_instructions: Some(Some(COLLABORATION_MODE_PLAN.to_string())),
    }
}

fn default_preset() -> CollaborationModeMask {
    CollaborationModeMask {
        name: ModeKind::Default.display_name().to_string(),
        mode: Some(ModeKind::Default),
        model: None,
        reasoning_effort: None,
        developer_instructions: Some(Some(default_mode_instructions())),
    }
}

fn default_mode_instructions() -> String {
    let known_mode_names = format_mode_names(&TUI_VISIBLE_COLLABORATION_MODES);
    COLLABORATION_MODE_DEFAULT_TEMPLATE
        .render([(KNOWN_MODE_NAMES_TEMPLATE_KEY, known_mode_names.as_str())])
        .unwrap_or_else(|err| panic!("collaboration mode default template must render: {err}"))
}

fn format_mode_names(modes: &[ModeKind]) -> String {
    let mode_names: Vec<&str> = modes.iter().map(|mode| mode.display_name()).collect();
    match mode_names.as_slice() {
        [] => "none".to_string(),
        [mode_name] => (*mode_name).to_string(),
        [first, second] => format!("{first} and {second}"),
        [..] => mode_names.join(", "),
    }
}

#[cfg(test)]
#[path = "collaboration_mode_presets_tests.rs"]
mod tests;

View on GitHub (pinned to 339751715c)

Solutions

Make every placeholder in DEFAULT exactly KNOWN_MODE_NAMES, or extend the render tuple in default_mode_instructions() with the new key when intentionally adding one.
Run the preset tests so the failure is caught at test time instead of first user request.
If a rename happened, grep the template text for the old placeholder name and update it.

Example fix

// before: template uses a placeholder the renderer never supplies
// const DEFAULT: &str = "Modes: {{MODE_LIST}}";
// after: match the one key default_mode_instructions() renders
// const DEFAULT: &str = "Modes: {{KNOWN_MODE_NAMES}}";

Defensive patterns

Strategy: validation

Validate before calling

// Render with the exact key production code supplies; fails in CI if the template drifts
#[test]
fn default_template_renders_with_known_key() {
    COLLABORATION_MODE_DEFAULT_TEMPLATE
        .render([(KNOWN_MODE_NAMES_TEMPLATE_KEY, "Plan and Default")])
        .expect("default template must render");
}

Try / catch

Panic, not an error value: do not attempt to catch. Fix by aligning every placeholder in the template with the keys passed in default_mode_instructions().

Prevention

When adding a placeholder to the template, extend the render tuple in the same commit.
After renaming KNOWN_MODE_NAMES_TEMPLATE_KEY, grep the template constants for the old name.
Keep a render test as the tripwire in collaboration_mode_presets_tests.rs.

When it happens

Trigger: DEFAULT references any placeholder other than {{KNOWN_MODE_NAMES}} (default_mode_instructions() passes exactly one key/value pair to render), or a renamed KNOWN_MODE_NAMES_TEMPLATE_KEY left the template text stale. The panic surfaces on the first call to builtin_collaboration_mode_presets().

Common situations: Adding a new placeholder to the prompt without extending the render tuple; renaming the key constant; a template grammar that defers some validation from parse time to render time.

Related errors

AI-assisted analysis of openai/codex@339751715c (2026-08-25). Data as JSON: /api/errors/5d6cd514e71d35e1. Report an issue: GitHub.