KyaOs.Checkpoint
0.3.0
See the version list below for details.
dotnet add package KyaOs.Checkpoint --version 0.3.0
NuGet\Install-Package KyaOs.Checkpoint -Version 0.3.0
<PackageReference Include="KyaOs.Checkpoint" Version="0.3.0" />
<PackageVersion Include="KyaOs.Checkpoint" Version="0.3.0" />
<PackageReference Include="KyaOs.Checkpoint" />
paket add KyaOs.Checkpoint --version 0.3.0
#r "nuget: KyaOs.Checkpoint, 0.3.0"
#:package KyaOs.Checkpoint@0.3.0
#addin nuget:?package=KyaOs.Checkpoint&version=0.3.0
#tool nuget:?package=KyaOs.Checkpoint&version=0.3.0
AI agent detection and policy enforcement for any .NET HTTP server. Install this metapackage and NuGet automatically pulls in the right adapter for your runtime: Checkpoint.AspNetCore on modern .NET (ASP.NET Core 6+), or Checkpoint.AspNet on classic .NET Framework 4.6.2+ (System.Web / IIS). Same WASM-backed Rust detection engine on both stacks — same patterns, same scoring, same updates.
Learn more about Target Frameworks and .NET Standard.
-
.NETFramework 4.6.2
- Checkpoint.AspNet (>= 0.3.0)
-
net8.0
- Checkpoint.AspNetCore (>= 0.3.0)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 1.2.2 | 4 | 6/10/2026 |
| 1.2.1 | 39 | 6/10/2026 |
| 1.2.0 | 45 | 6/10/2026 |
| 1.1.0 | 60 | 6/8/2026 |
| 1.0.3 | 168 | 5/28/2026 |
| 1.0.2 | 129 | 5/27/2026 |
| 1.0.1 | 156 | 5/20/2026 |
| 1.0.0 | 143 | 5/18/2026 |
| 0.4.0 | 159 | 4/22/2026 |
| 0.3.3 | 158 | 4/21/2026 |
| 0.3.2 | 153 | 4/21/2026 |
| 0.3.1 | 159 | 4/18/2026 |
| 0.3.0 | 159 | 4/18/2026 |
| 0.2.9 | 162 | 4/18/2026 |
| 0.2.8 | 162 | 4/17/2026 |
| 0.2.7 | 167 | 4/17/2026 |
| 0.2.6 | 154 | 4/17/2026 |
| 0.2.5 | 158 | 4/17/2026 |
| 0.2.4 | 157 | 4/17/2026 |
| 0.2.3 | 156 | 4/17/2026 |
0.3.0 — Hang fix follow-up to 0.2.9 (CRITICAL for anyone on 0.2.4–0.2.9)
0.2.9 (#1829) added ConfigureAwait(false) and a relative-URL fix in
McpInstructBuilder. 0.3.0 builds on that with the bounded-fetch +
negative-cache + URL-validation work needed to actually prevent the
hardwareworld.com class of hang, not just the synchronization-context
amplification of it. Anyone running 0.2.4–0.2.9 should upgrade.
Changes:
* PolicyEvaluator: cap lock-wait at 2s and policy-fetch at 3s via linked
CancellationTokenSource. Worst-case per-request policy time bounded
regardless of HttpClient timeout or retry behavior.
* PolicyEvaluator: short (10s) negative cache after a failed/null fetch so
one slow backend doesn't cascade into per-request retries serialised
through the SemaphoreSlim.
* PolicyEvaluator: stale-on-failure — if a refresh fails, keep serving the
last-known-good policy rather than dropping to local-only enforcement.
* CheckpointModule / UseCheckpoint(): pre-warm the policy cache on
initialization so the first real request never pays the cold-cache cost.
* CheckpointApiClient: per-call retry budget (1 retry, 3s total) for
policy fetches; telemetry endpoints unchanged.
* PolicyCacheTtlMinutes default raised from 1 → 5 to cut steady-state
policy traffic 5×. Set lower explicitly for rapid-rollout setups.
* ConfigureAwait(false) added to all library awaits (CheckpointModule,
CheckpointMiddleware, PolicyEvaluator, CheckpointApiClient,
SignatureVerificationHelper) — eliminates classic ASP.NET sync-context
amplification on the .NET Framework adapter.
* Redirect branches now reject non-absolute / non-http(s) URLs from
policy.RedirectUrl and Checkpoint:McpServerUrl. A relative URL like
"/connect/{projectId}" used to 302 the request back into the customer's
own host, looping through the same module and surfacing as a hung
connection. When neither the policy URL nor the local McpServerUrl is
an absolute http(s) URL, the module falls through to the default block
response and emits a Trace warning identifying which value(s) were
malformed. UrlHelpers.TryResolveAbsoluteRedirect / IsAbsoluteHttpUrl
added for both adapters.
Note: Checkpoint.FailOpen catches *exceptions*, not *hangs*. Before 0.2.9
a slow policy fetch never threw, so FailOpen=true did not protect the
request path. With 0.2.9 the bounded-wait CTS makes this distinction
mostly moot, but the underlying behavior is unchanged.