How Caisey's Headless Runtime Lets Technicians Diagnose a Locked Endpoint Without User Interaction

You get a ticket: "Server crashed last night, can you check the event logs?" You call the client. No answer. The machine is locked, sitting at the login screen. With traditional remote tools, you're stuck. You need someone to log in, or at least accept a screen-share request. But what if you could start diagnosing right now, without waiting for a person to be present?

That's exactly what Caisey's headless runtime is built for. It runs in the background, enrolled on the device, and reachable from the cloud console regardless of whether a user is logged in or the screen is locked. You don't need a user to click "accept" — you just need the right permissions and a browser tab.

The Common Frustration: Locked Screens and Unavailable Users

Every MSP technician has been there. A critical issue comes in after hours or during a meeting. The endpoint is powered on, but the user is away. Maybe it's a server that auto-locks after 15 minutes of inactivity. Maybe it's a workstation that rebooted overnight and is sitting at the Windows login prompt.

With tools like ScreenConnect or TeamViewer, you can't start a remote session until someone on the other end accepts the invitation or enters a code. Even RMM agents that offer remote desktop often require an active user session to interact with the desktop. If the machine is locked, you're dead in the water until someone physically logs in.

This delay costs time. It turns a five-minute log check into a 45-minute back-and-forth. And if the user is in a different time zone or on vacation, you might not get access until the next day.

How Caisey's Headless Runtime Works

Caisey takes a different approach. The Caisey runtime is a lightweight agent that runs as a system service on Windows and macOS. It's enrolled to your Caisey organization and communicates via a Cloudflare Worker control plane using WebRTC and Durable Objects. The runtime is always active, even when no user is logged in. It doesn't depend on a user session to maintain connectivity.

From the Caisey console, you see a list of enrolled machines. Each machine card shows its status — online, offline, or unreachable. If the machine is powered on and has network access, it's reachable. You can click into it and start a session. No prompts appear on the endpoint screen. No user needs to click "Allow."

This is possible because the runtime operates independently of the interactive desktop. It can execute commands, read event logs, check registry keys, and return results directly to your browser. The session is recorded, and any commands that require elevated privileges are gated by pre-configured approval policies.

Concrete Scenario: After-Hours Server Crash

Let's make this real. A client's file server crashed at 2 AM. The server rebooted and is now sitting at the Windows login screen. The client's IT contact is asleep. You need to check the System event log for the crash reason and verify that services started correctly.

With Caisey:

1. Open the Caisey console in your browser.
2. Search for the server by name or client group.
3. Click the machine card — it shows "Online."
4. Click "Start Session."
5. The session begins. You see a command prompt interface in the console.
6. Run Get-WinEvent -LogName System -MaxEvents 20 | Where-Object { $_.LevelDisplayName -eq 'Error' } (or the equivalent Caisey command).
7. Within seconds, the runtime returns the last 20 error events from the System log.
8. You identify a disk driver failure. You note the error code and timestamp.
9. You end the session. The entire interaction is recorded in Durable Session History.

No one had to log in. No screen share was needed. You got the information you needed and can now plan the fix for business hours.

The Approval Gate for Unattended Access

You might be thinking: "If Caisey can access a locked machine without user interaction, what stops a technician from running wild?" That's where approval gates come in.

Caisey's permission model is configurable. For unattended access, the client organization can set policies that require pre-approval for any session that starts without an active user. For example, a policy might require that the technician has a specific role, that the session is logged and auditable, and that any command that modifies the system (like a registry edit or service restart) prompts a secondary approval from a client-designated contact.

In the scenario above, the technician only ran read-only commands — inspecting event logs. That might be allowed under a blanket policy for after-hours diagnostics. If the technician needed to restart a service, Caisey would either require an approval from a client contact (via email or push notification) or fall back to a scheduled maintenance window.

This gives the client control without blocking urgent diagnostics. The approval gate is not a binary on/off switch; it's a configurable rule that can differentiate between read and write actions.

Comparison to Traditional Tools

How does this stack up against what you're using now?

• **ScreenConnect / TeamViewer**: Require an interactive user to accept the session. If the machine is locked, you can't connect. Some versions support unattended access with a stored password, but that still requires the remote desktop protocol to be active, and the user must have logged in at least once. If the machine is at the login screen, remote desktop won't work.
• **RMM remote desktop (e.g., NinjaRemote, Datto RMM)**: These often rely on Windows RDP or VNC, which require an active user session. Some RMMs offer a "remote command" feature that runs as system, but the output is often limited to a text box, and there's no session context or audit trail.
• **SSH / WinRM**: These can work without a user session, but they require network configuration, open ports, and credentials. For many MSPs, enabling WinRM across client networks is a security risk and a management headache.

Caisey combines the best of both worlds: the ease of a cloud-managed agent with the ability to run commands in a system context, all without exposing traditional remote access protocols.

The Caisey Workflow Step by Step

Here's a repeatable workflow for diagnosing a locked endpoint:

1. **Enroll the device**: Install the Caisey runtime on the endpoint. This can be done via your RMM, a GPO, or a one-time link. Once enrolled, the runtime appears in your console.
2. **Verify machine status**: From the console, check that the machine shows "Online." If it's offline, you'll need to power it on or check network connectivity.
3. **Initiate a session**: Click the machine card and select "Start Session." The session begins immediately if your role and the client policy allow unattended access.
4. **Run diagnostics**: Use the built-in command interface or Caisey's AI-assisted troubleshooting to run checks. Examples:

• Check disk space: Get-PSDrive C | Select-Object Used, Free
• Check recent crashes: Get-WinEvent -FilterHashtable @{LogName='Application'; ID=1000} -MaxEvents 5
• Check service status: Get-Service Spooler, W3SVC

1. **Review results**: The output appears in the console. You can copy it, annotate it, or share it with a colleague via a public transcript share.
2. **End the session**: Close the session. The entire transcript is saved in Durable Session History, including timestamps, commands, and outputs.
3. **Document the ticket**: Paste the relevant findings into your PSA. Link to the session transcript for future reference.

Why This Matters for MSPs

The ability to diagnose a locked endpoint without user interaction changes the economics of after-hours support. You no longer need to wake up a client contact just to ask them to log in. You can triage issues faster, reduce mean time to diagnose, and provide better service without adding overhead.

It also improves security. Because Caisey doesn't require opening RDP ports or storing shared passwords, the attack surface is smaller. Every session is audited, and unattended access is governed by policy, not by a saved password file.

For MSP technicians, this means fewer frustrating calls and more time spent actually fixing problems. The next time a server crashes at 2 AM, you can start working immediately — even if no one is there to let you in.