Add a first-party .NET client

[Josh (joshmouch)]

A first-party .NET / NuGet client for AHP 1.0, at cross-language parity with the Rust, Kotlin, Swift, TypeScript, and Go clients.

What’s included

• Microsoft.AgentHostProtocol.Abstractions: generated wire types plus transport and serializer interfaces.
• Microsoft.AgentHostProtocol: reducers, AhpClient, integrated WebSocketTransport, and MultiHostClient.
• Multi-targeted shipping libraries for netstandard2.0 and net8.0; tests and examples run on net8.0.
• C# code generation from the canonical TypeScript protocol types, wired into generated-source freshness checks.
• Shared reducer and round-trip fixture coverage, including the AHP 1.0 automation channels.
• CI build, test, format, pack, changelog-fragment, and release-metadata integration.

Validation

• 496 .NET tests pass with no skips.
• Both NuGet packages build for netstandard2.0 and net8.0 and pack successfully.
• Repository typecheck, lint, metadata, changelog, generated-source, and protocol tests pass.

Ownership and publishing

I’m happy to continue maintaining the .NET client and keep it in protocol parity. Package IDs remain Microsoft.AgentHostProtocol.*; publishing can be wired to the maintainers’ signed NuGet pipeline.

[Wiktor Kopec (wiktork)]

Josh (@joshmouch) are you still interested in making this contribution? Our team has interest here and the AHP folks encouraged us to start with your changes.

• The current PR would need some updates to the protocol.
• We have a requirement around targeting netstandard2.0.

[David Fowler (davidfowl)]

Security follow-up on \FileClientIdStore: the temporary file currently receives the client ID before its Unix permissions are tightened to \

[Josh (joshmouch)]

Thanks Wiktor Kopec (@wiktork) — and yes, absolutely still interested! Genuinely thrilled this ended up being the starting point for your team; honestly that's the best outcome I could have hoped for here. Apologies for the slow reply.

Both of your points are covered now, thanks to David Fowler (@davidfowl):

• netstandard2.0 — already good: the client multi-targets netstandard2.0;net8.0, and Harden .NET client security, reconnects, and Native AOT #411 keeps that split intact even on the security-sensitive paths (native open(2)/fchmod on the netstandard2.0 leg, where FileStreamOptions.UnixCreateMode isn't available).
• protocol updates — the 1.0 adoption landed with the merge.

David Fowler (@davidfowl) — #411 is a great read, and the FileClientIdStore catch is a sharp one. While going through it I spotted the same issue in the Swift client, which the .NET store was ported from: store() writes the id to the final path and only chmods to 0600 afterwards, so the first store for a given host id sits at 0644 in between. The store's own 0700 directory hardening doesn't cover it either — ensureDirectory() only applies it on the branch where it creates the directory, so a pre-existing app-support or XDG path keeps its own mode. Worth flagging that neither client's test would catch this: both assert the mode after store() returns, so they're green either way.

Written up separately rather than widening #411 — happy to open the Swift PR if that's useful.

Really glad to keep helping here — this has been a genuinely fun one to work on.