What are you proposing?
Expand the Linux platform target identifiers in the registry schema to distinguish between glibc (gnu) and musl libc variants. For example:
linux-x86_64-gnu (dynamically linked against glibc, current default behaviour)linux-x86_64-musl (statically linked against musl, for Alpine and similar)linux-aarch64-gnulinux-aarch64-musl
The existing linux-x86_64 and linux-aarch64 identifiers could be retained as aliases for the glibc variants to preserve backwards compatibility with already-registered agents.
Why does this matter?
A Linux binary compiled against glibc will fail to run on musl-based systems (Alpine Linux, Void, Wolfi, distroless containers, etc.), and the reverse is also true. Many agents, especially those written in Rust already ship separate *-unknown-linux-gnu and *-unknown-linux-musl release artifacts precisely because of this. Without a way to express
the distinction in the registry, agents are forced to either:
- Ship only the glibc build and silently break on musl-based environments, or
- Pick musl (fully static) as a lowest-common-denominator, potentially sacrificing performance or compatibility with glibc-only system libraries.
First-class musl target support would let registry entries surface the right binary for the user's environment automatically, rather than leaving it to manual configuration.
Are there any examples or context?
Rust's standard target triple naming already encodes this distinction:
x86_64-unknown-linux-gnux86_64-unknown-linux-muslaarch64-unknown-linux-gnuaarch64-unknown-linux-musl
Most multi-platform Rust CLI tools (including agents like Stakpak, VT Code, Goose etc. that are already ACP-compatible) publish separate release artifacts for both, and would benefit from being able to register both variants.
Possible approach
- Add
linux-x86_64-gnu, linux-x86_64-musl, linux-aarch64-gnu, linux-aarch64-musl as valid platform keys in agent.schema.json and the validation logic in build_registry.py.
- Keep the existing bare
linux-x86_64 / linux-aarch64 keys valid and treat them as equivalent to the -gnu variants for backwards compatibility.
- Update
FORMAT.md and CONTRIBUTING.md to document the new keys and recommend shipping both libc variants where possible.
- Optionally, update the cross-platform coverage warning logic to treat
*-gnu and *-musl as complementary rather than duplicates of the same OS family.
What are you proposing?
Expand the Linux platform target identifiers in the registry schema to distinguish between glibc (
gnu) and musl libc variants. For example:linux-x86_64-gnu(dynamically linked against glibc, current default behaviour)linux-x86_64-musl(statically linked against musl, for Alpine and similar)linux-aarch64-gnulinux-aarch64-muslThe existing
linux-x86_64andlinux-aarch64identifiers could be retained as aliases for the glibc variants to preserve backwards compatibility with already-registered agents.Why does this matter?
A Linux binary compiled against glibc will fail to run on musl-based systems (Alpine Linux, Void, Wolfi, distroless containers, etc.), and the reverse is also true. Many agents, especially those written in Rust already ship separate
*-unknown-linux-gnuand*-unknown-linux-muslrelease artifacts precisely because of this. Without a way to expressthe distinction in the registry, agents are forced to either:
First-class musl target support would let registry entries surface the right binary for the user's environment automatically, rather than leaving it to manual configuration.
Are there any examples or context?
Rust's standard target triple naming already encodes this distinction:
x86_64-unknown-linux-gnux86_64-unknown-linux-muslaarch64-unknown-linux-gnuaarch64-unknown-linux-muslMost multi-platform Rust CLI tools (including agents like Stakpak, VT Code, Goose etc. that are already ACP-compatible) publish separate release artifacts for both, and would benefit from being able to register both variants.
Possible approach
linux-x86_64-gnu,linux-x86_64-musl,linux-aarch64-gnu,linux-aarch64-muslas valid platform keys inagent.schema.jsonand the validation logic inbuild_registry.py.linux-x86_64/linux-aarch64keys valid and treat them as equivalent to the-gnuvariants for backwards compatibility.FORMAT.mdandCONTRIBUTING.mdto document the new keys and recommend shipping both libc variants where possible.*-gnuand*-muslas complementary rather than duplicates of the same OS family.