Crash Override workspace sensor
Prompt to production provenance.
The workspace sensor is the developer-machine surface of the data plane.
Linux
Run this in a terminal. It asks for sudo once.
curl -fsSL https://get.crashoverride.run/endpoint/linux | bash More options
As root, or in automation with no terminal:
curl -fsSL https://packages.crashoverride.run/install.sh | sudo sh To uninstall:
curl -fsSL https://get.crashoverride.run/endpoint/linux | bash -s -- --uninstall The workspace sensor is available for macOS, Windows and Linux.
We watch the agents. We are not one of them.
The workspace sensor runs on the developer's machine and observes AI-assisted engineering: which AI coding tools are used (Claude Code, Cursor, Copilot, Codex, Devin), what they were asked to do, what they produced, and how that work moves into the build and out to production. Everything it observes lands in the same data plane as the build sensor's records and what's running in production. The workspace sensor extends the data plane to the machine where the code is written.
Action-level detail, not a summary.
Observed on the machine, deterministically. No model sits in the data path guessing about your code.
- Sessions
- For transcript-backed tools such as Claude Code and Codex: the prompts and responses themselves, tied to the user, the files, the tools and the network activity around them.
- Actions
- Tool calls, denied tool use, shell execution with exit codes, and file create, modify and delete.
- MCP
- First-class visibility into Model Context Protocol activity: server starts, tool calls and references.
- Network
- External calls the agent initiates: DNS, URLs, methods, status codes and provider routes.
- Attribution
- Agent-to-source and engineer-to-source attribution, with provider, model and session identity.
- Timeline
- A session-level unified timeline joining AI activity to source change, build, deploy and runtime.
Zero-touch through your MDM, or one machine at a time.
The workspace sensor ships zero-touch through the MDM you already run. There is no developer opt-in, no IDE plugin, no Dockerfile change and no CI configuration, so coverage does not depend on every team remembering to instrument every repo.
-
Zero-touch rollout
Deployed through your existing MDM. No developer opt-in required.
-
MDM optional
MDM is the easy path, not a requirement. You can install the workspace sensor on a single machine from this page.
-
Generally available
The workspace sensor is available for macOS, Windows and Linux: Apple Silicon Macs on macOS Tahoe 26.0 or later, Windows 11 on x64 and ARM64, and Linux.
-
Optional for the build sensor
The build sensor works without the workspace sensor. The workspace sensor extends the same thread left, to the machine where the code is now written.
Session timeline
Prompt to commit, in one thread
- E004 Prompt fix the payment retry logic
- E009 Plan 3 steps proposed · accepted
- E012 Read payments/retry.ts · 412 lines
- E018 Edit payments/retry.ts · +12 −4
- E024 Shell test suite · exit 0 · 124 passed
- E031 Commit signed · queued for build
Action-level audit
What the agent actually did
- A017 server.start issue-tracker
- A019 tool.call search_issues
- A023 tool.call read_file
- A026 tool.call write_file denied
- A031 reference spec/retry-policy
Before you install.
The workspace sensor is available for macOS, Windows and Linux. On macOS it needs an Apple Silicon Mac running macOS Tahoe 26.0 or later. On Windows it needs Windows 11, on x64 or ARM64. On Linux, it installs with one terminal command.
No. MDM is the easiest way to roll the workspace sensor out across a fleet with no developer opt-in, but it is not required: you can install it on a single machine from this page.
Everything the workspace sensor observes lands in the same data plane as the build sensor's records and what's running in production. It records what AI coding tools did (prompts, tool calls, file changes, commits), not what the human typed outside that context, and it captures no keystrokes or screen content outside the coding context.