Goose: entry written by install lacks required name

[SynthLuvr]

Version

codebase-memory-mcp 0.10.5

Platform

Linux (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

codebase-memory-mcp install completes successfully against a clean goose 1.45.0 config (no envs: {} lines, so #1673 does not trigger), detects Goose, and writes the codebase-memory-mcp entry under extensions: in ~/.config/goose/config.yaml. goose then silently ignores that entry:

• it never appears in goose configure → Toggle Extensions, and
• sessions start without the CBM tools (verified: a goose session asked to call list_projects reports the tool as unavailable).

Expected: the entry install writes parses under goose's config schema, so the extension is listed and enabled.

Root cause (verified against v0.10.5 source and goose v1.45.0 source)

The goose branch of cbm_build_yaml_stdio_mcp_block (src/cli/cli.c, goose_schema=true) emits exactly:

    type: stdio
    cmd: <binary path>
    args: []
    enabled: true

goose's ExtensionConfig::Stdio declares name as a required serde field with no default (crates/goose/src/agents/extension.rs @ v1.45.0):

#[serde(rename = "stdio")]
Stdio {
    /// The name used to identify this extension
    name: String,
    ...
}

and goose's config loader drops any entry that fails deserialization, silently, at info! level (crates/goose/src/config/extensions.rs, parse_extensions_map):

Err(err) => {
    info!(key = %key, error = %err, "Skipping malformed extension config entry");
}

No error surfaces anywhere: the installer reports success, goose reports nothing, and the entry sits inert in the file. Two consequences worth noting:

• The first time goose rewrites the extensions: section (e.g. toggling any extension in goose configure), the unparseable entry is removed from the file entirely, because goose re-serializes the parsed map (with_raw_extensions_mapping).
• Every entry goose itself serializes for a stdio extension carries name: (see the linux-mcp-server example quoted in Goose: op=mcp_install refuses any config goose itself serialized #1673); the canonical block here is the odd one out. Notably, Goose: op=mcp_install refuses any config goose itself serialized #1673's workaround ends at "writes the entry, and the server passes a stdio MCP handshake" — the handshake proves the server works standalone, but on goose 1.45.0 the written entry still never loads due to this missing field.

Workaround (verified end-to-end on goose 1.45.0)

Give the entry the fields goose itself serializes for stdio extensions — only name is load-bearing:

  codebase-memory-mcp:
    enabled: true
    type: stdio
    name: codebase-memory-mcp
    description: Codebase knowledge graph MCP server (tree-sitter)
    cmd: /home/<user>/.local/bin/codebase-memory-mcp
    args: []
    env_keys: []
    timeout: 300

After this change: the extension appears in Toggle Extensions, sessions load it, and a live list_projects call made through goose returns:

{"projects": [], "hint": "No projects indexed. Call index_repository(repo_path=...) first."}

A hand-edited entry also survives future install/update runs: yaml_edit_owned_mapping_entry_locked compares the existing entry against the canonical block and returns CBM_YAML_IDENTITY_EDIT_FOREIGN (leaves it untouched) instead of overwriting — correct behavior for user-owned entries; the canonical block itself just needs to be valid goose schema.

Suggested fix direction

Add name: codebase-memory-mcp to the goose_schema branch of cbm_build_yaml_stdio_mcp_block; optionally mirror goose's own serialization (description, env_keys: [], timeout: 300) to minimize churn when goose re-serializes. Related: #1673 (same writer, different failure mode — that one refuses to write on configs goose itself serialized; this one writes an entry goose silently discards), #728 (original Goose support request).

Reproduction

Pure config round-trip — no code involved, dummy content only, sandboxed $HOME (real config untouched). All output below is from an actual run against the 0.10.5 release binary:

1. Fresh fake goose home with an empty extensions: mapping:

CBM="$(command -v codebase-memory-mcp)"
mkdir -p "$HOME/cbm-repro/.config/goose"
printf 'extensions: {}\n' > "$HOME/cbm-repro/.config/goose/config.yaml"
env HOME="$HOME/cbm-repro" "$CBM" install -y

2. Installer output:

Detected agents: Goose

Goose:
  mcp: /home/<user>/cbm-repro/.config/goose/config.yaml
  instructions: /home/<user>/cbm-repro/.config/goose/.goosehints

and the resulting config (complete file):

extensions:
  codebase-memory-mcp:
    type: stdio
    cmd: "/home/<user>/cbm-repro/.local/bin/codebase-memory-mcp"
    args: []
    enabled: true

grep -c "name:" on that file returns 0 — the one field goose requires is absent.

3. Present that config to goose 1.45.0: the extension is absent from goose configure → Toggle Extensions, and a session asked to call list_projects reports the tool unavailable. The only trace is an info-level Skipping malformed extension config entry line in goose's logs; nothing is surfaced in goose configure or session output.

4. Add name: codebase-memory-mcp to the entry and repeat step 3 → the extension is listed, loads, and the tool call succeeds.

Logs

Installer: exits successfully, no warnings. goose: nothing user-visible — the skip is only the `info`-level log line quoted in the root cause. Happy to attach the exact serde error payload if useful.

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.