Oliver Kieselbach
04fae4fe86
* bump pointer: internal (ingest-session-row-reads RELEASED, measurement) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Web Push channel: alerts to paired phones without a third-party messenger (D-327 to D-330) Provider WebhookProviderType.Push = 50 in both channel scopes. It carries no destination; NotificationChannelDispatcher takes a NotificationScope from every caller and the push transport resolves the scope's paired devices at send time (table-backed Admin/Operator, GlobalAdmin with matching identity binding; Viewer and Global Reader never). The receiver never signs in: a signed-in Admin/Operator creates a one-shot pairing code (11 Crockford chars, hashed, 10 min, ETag one-shot, five-failure burn), the phone redeems it anonymously, the portal session confirms. The phone's only credential is the device token in X-Push-Device-Token, good for status, re-subscribe and unpair of its own row (10 calls per minute per device; the anonymous pairing routes 10 per minute per IP). Payloads are RFC 8291 per device (new BCL-only library src/Push with the RFC vector pinned byte for byte) with a VAPID key ring and the kid on every device row; the projection reads an allow-list only (never Sections, DataJson, Failure Reason, Last Failure or the ops message), serial masked, 2 KB. 404/410 mark a device Stale instead of deleting it and the receiver re-arms it on its next open (the same PUT lifts a delivery-failures pause); devices pause when their owner stops signing in (PushOwners stamp in auth/me) through one pause path and resume by themselves; an owner without a stamp is paused, never deleted outright; role loss revokes with a wipe push and deletes the row (there is no Revoked state). PushDevices and PushPairingGrants are credential-bearing: raw-table deny-list, no backup, redacted dependency rows. Receiver app under /push/ (module service worker, Declarative Web Push shape, local history, pairing and status pages, manifest + icons), portal UI (Push provider in the channel editor, pairing dialog with QR code, device lists for tenant and platform scope, "Notify me when done" on the session page — the watch row records the watcher's own scopes, so a Global Admin watching a customer session is notified on the platform-paired phone), 22 catalogued routes, ops events PushDeliveryFailed and PushEndpointRefused (deduplicated per instance), maintenance sweep inside the existing run, settings template. The tenant-scope provider stays Global-Admin-only until the customer release (same ValidateModel gate as Telegram). Backend 7371, library 125, MCP 997, web 2061 tests. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * bump pointer: internal, .claude/commands, infra (push-relay: plan, D-327 to D-330, markers, VAPID generator) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * bump pointer: internal (push-relay: commit step ticked) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Drop sprintf-js from both lockfiles (Dependabot #114, #117) GHSA-hp3w-g68c-fv3c (sprintf-js <= 1.1.3, denial of service through unbounded precision specifiers) has no patched release, so both chains are cut instead. MCP (#117): sprintf-js arrived via @huggingface/transformers -> onnxruntime-node -> global-agent 3 -> roarr. global-agent is only loaded by onnxruntime-node's CUDA install script, which the image never runs (npm ci --ignore-scripts). The override global-agent ^4.1.3 drops roarr; 4.x keeps the bootstrap export that script calls, and onnxruntime-node 1.30 depends on the same range. Rules tooling (#114): ajv-cli 5.0.0 (no release since 2023) pulled js-yaml 3 -> argparse 1 -> sprintf-js. rules/scripts/validate.js now checks the four rule sets against their schemas with ajv (draft 2020-12) and ajv-formats directly, and combine-rules.yml runs it in one step instead of four ajv-cli loops. The lockfile shrinks from 26 to 6 packages; the fast-json-patch override and the legacy-peer-deps .npmrc (only there for ajv-cli's ts-node peer) are gone. Verified: validate.js accepts all 149 rule files plus guardrails.json exactly as ajv-cli did and rejects a corrupted copy (missing field, broken JSON, U+2028 in a guardrail value) with exit 1; clean npm ci + combine.js leave the generated outputs unchanged; MCP build and 997 tests green; zizmor clean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * bump pointer: internal, .claude/commands (validate.js replaces ajv-cli: B-gzv, rule-builder fallback) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Bump sharp, proxy-addr and source-map-js past fresh advisories (MCP, Web) - sharp 0.35.4 -> 0.35.5 (GHSA-wq5f-xc86-pv6w, librsvg): the existing sharp override in both projects now floors at ^0.35.5 so the fixed build cannot be undercut by a parent range. - proxy-addr 2.0.7 -> 2.0.8 (GHSA-jqcg-44mw-7w3h, via express; MCP only) and source-map-js 1.2.1 -> 1.2.2 (GHSA-68fv-2mgg-jv7q, via postcss) are lockfile-only bumps inside the ranges their parents declare. No other lockfile entry moved. npm audit in the MCP server is clean. Verified: MCP build and 997 tests green; Web tsc clean, 2061 tests green, next build (static export) succeeds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * bump pointer: internal (push-relay: CORS verified, cert-exclusion prerequisite, EU app facts) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Web: Next.js 16.3.6 -> 16.3.8 (six advisories) 16.3.8 closes GHSA-3w37-wq28-93x7, GHSA-4jqv-mc3x-m676, GHSA-39w2-rjm5-chcv, GHSA-f87g-xv8r-7p7x, GHSA-mcj8-r9mp-w47p and GHSA-cjq9-62q9-8jv4 (affected 16.0.0 - 16.3.7). Under output:"export" the cache, ISR and image-optimization paths never run on the SWA; the dev-server disclosure is local-only. The patch is taken anyway. next, eslint-config-next and @next/bundle-analyzer stay aligned and floor at ^16.3.8; the lockfile is pinned to 16.3.8, not the 16.4.0 minor the caret would resolve to. What npm audit still reports (braces, micromatch, chokidar, fast-glob, postcss-selector-parser) comes through Tailwind 3 and eslint-config-next, build-time only; braces has no fix, the rest needs Tailwind 4 (backlog). Verified: tsc clean, eslint 0 findings, 2061 tests green, next build (16.3.8, 102 static pages) succeeds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * bump pointer: internal (B-dzs lockfile merge note, B-hxz braces chain) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Autopilot Monitor
Autopilot Monitor is an open-source, real-time monitoring and troubleshooting platform for Windows Autopilot and Microsoft Intune enrollment. It records enrollment events, application installations, policies, device state, and diagnostics while provisioning is still running, instead of collecting logs by hand after a failure. Administrators get live enrollment tracking, Enrollment Status Page (ESP) visibility, detailed session timelines, automated issue detection, on-demand diagnostics, fleet health analytics, and AI-assisted troubleshooting through a hosted Model Context Protocol (MCP) server.
The platform supports classic Windows Autopilot and modern Intune provisioning scenarios, including Windows Autopilot Device Preparation.
Availability
Autopilot Monitor is publicly available — the Community plan is free. Sign in with your work account at autopilotmonitor.com; new organizations complete a short activation step after first sign-in.
Key Features
- Real-time Windows Autopilot monitoring — follow device provisioning while enrollment is still running
- Detailed enrollment timelines — correlate Autopilot, ESP, Intune Management Extension, apps, policies, device state, and system events
- Enrollment Status Page visibility — see which phase, application, or policy is delaying provisioning
- Automated issue detection — define custom analysis rules that identify known failure patterns
- Targeted evidence collection — gather registry values, event log entries, files, log-parser matches, and allow-listed commands when specific conditions are detected
- On-demand diagnostics — request diagnostics packages from enrolled devices remotely
- Fleet health analytics — success rates, deployment duration, device models, applications, errors, and recurring issues
- Session reporting — inspect and share detailed enrollment information for individual devices
- Windows Autopilot Device Preparation support — monitor Device Preparation deployments alongside classic Autopilot scenarios
- Centralized agent configuration — control diagnostic behavior, automatic reboots, timezone adjustment, and other monitoring settings from the web dashboard
- AI-assisted troubleshooting — query enrollment data through the built-in Model Context Protocol server
How it works
Autopilot Monitor consists of several components working together throughout Windows enrollment:
- Bootstrap Script — PowerShell script deployed through Microsoft Intune that starts monitoring early in the provisioning process
- Monitoring Agent — lightweight .NET application that collects telemetry and evidence during enrollment
- Backend API — Azure Functions-based ingestion and processing pipeline
- Web Dashboard — Next.js application for real-time monitoring, troubleshooting, and fleet analytics
- MCP Server — Model Context Protocol server that lets AI assistants query Autopilot Monitor data in natural language
Windows Autopilot and Intune Troubleshooting
Autopilot Monitor helps investigate common Windows provisioning and enrollment problems such as:
- Windows Autopilot deployments that fail or appear stuck
- Enrollment Status Page (ESP) delays and unusually long deployment phases
- Win32 application installation failures and slow application downloads
- Intune Management Extension problems
- Microsoft Entra join, Hybrid Join, and device registration issues
- policies that block or delay provisioning
- inconsistent behavior across hardware models and recurring failures affecting multiple devices
Because telemetry is collected during enrollment, many problems can be investigated without reproducing the issue or manually collecting logs from the affected device.
AI Integration (MCP)
Autopilot Monitor ships a hosted Model Context Protocol server. Connect Claude Desktop, VS Code, or any MCP client that speaks Streamable HTTP with OAuth, and ask questions like:
- "Show me all failed enrollments from the last 24 hours and group them by failure reason."
- "Why did session X fail, and which app install caused the delay?"
- "Which devices had unusually long ESP application phases this week?"
- "Which device models have the highest Autopilot failure rate?"
- "Which devices in my fleet are affected by CVE-2024-30078?"
Server URL: https://mcp.autopilotmonitor.com/mcp — sign-in runs through your existing work account, access is scoped to your tenant exactly like in the portal, and the MCP server stores no credentials. Setup guide: AI Integration (MCP).
Documentation
Full admin documentation is available at docs.autopilotmonitor.com — deployment, configuration, monitoring, diagnostics, troubleshooting, analysis and gather rules, integrations, and AI-assisted troubleshooting.
Open Source
Autopilot Monitor is developed openly on GitHub. The source is published so that customers and security reviewers can see what runs on their devices and with their data: the repository contains the device agent, shared library, backend, web dashboard, and MCP server.
Feedback
Bug reports and feature requests go through Issues, questions and ideas through Discussions. Security issues are reported privately, see SECURITY.md. For a problem in your own tenant, the Report Session button in the portal is the fastest path.
License
This project uses a split licensing model. The root LICENSE is AGPL-3.0, which covers the server-side components; the device-side components carry their own MIT license file:
- MIT License — Agent (
src/Agent/) and Shared library (src/Shared/) — unrestricted use on end-user devices, no copyleft obligations - AGPL-3.0 — Backend (
src/Backend/), Web Dashboard (src/Web/), and MCP Server (src/McpServer/) — modifications to server-side components remain open source, especially when deployed as a network service
The Shared library is MIT because it is a dependency of the MIT-licensed Agent. The license file inside each component directory is authoritative for that component.