When AgentSight works without eBPF—and when it does not

The short answer

Use the no-eBPF path when the question can be answered from local agent state: which sessions exist, what model and token information the agent recorded, which native Tool actions are present, how coding activity moved through a repository, or which local session you want to open in the hosted app. AgentSight v1.0.30 explicitly documents native-session support for top, bind,vis, and report without requiring eBPF.

Use record or an eBPF-backed debug command when the question is independent system behavior: what processes actually executed, which files were opened at the kernel boundary, what resource activity happened, or which TLS/plaintext traffic crossed the instrumented runtime boundary. On Linux, those capture paths require the privileges needed to load the probes.

What works without eBPF

Workflow	No-eBPF input	Useful for	Important limit
`agentsight top`	Local agent sessions plus process snapshots.	Live session inventory, model/token state, process CPU/RSS, and a quick machine view.	Without eBPF privilege, it does not become an independent kernel event trace.
`agentsight bind`	Live host processes and the local agent-session index, or an explicit saved DB.	Opening local AgentSight data in the hosted or self-hosted browser UI.	The browser sees the evidence available to the Node; binding does not create missing system evidence.
`agentsight vis`	Matching local Claude, Codex, and Gemini sessions.	Repository replay and portable Agent Nebula artifacts.	Native Tool/file actions are not proof of every low-level filesystem effect.
`agentsight report`	Saved AgentSight DBs or supported local agent sessions, depending on the report.	Structured summaries, token analysis, native-session inspection, or saved-record queries.	The evidence lineage depends on whether the row came from a recording, reconstruction, or native session.

`top` is intentionally hybrid

The usage guide describes top as the normal live view and makes sudo optional. Without eBPF privileges, it falls back to process snapshots and agent-native sessions. If sudo is already available on Linux, AgentSight can enable the richer eBPF-backed live capture automatically. This makesagentsight top a useful first command on a laptop because the command remains useful even when the kernel tracing path is unavailable.

That convenience should not erase the source boundary. A native session can tell AgentSight about model, token, tool, and session facts that the agent persisted. A process snapshot can tell it what is running and expose current CPU/RSS. Neither source, by itself, proves the complete sequence of file and process events that an independent eBPF recording can observe.

`bind` is a presentation path, not a recording mode

Running agentsight bind starts a local Node and lets the browser query it. With no--db, v1.0.30 builds the Node around a live host view and the local session index. With--db, it serves a saved capture. The command is unprivileged because its job is to expose evidence AgentSight can already read; it does not silently start eBPF recording just because the hosted app is open.

This distinction is useful operationally. You can inspect native Claude, Codex, or Gemini history from a browser on macOS or Windows, or on a Linux machine where you do not want to grant probe-loading privilege. If the investigation later needs independent system events, reproduce the workload underrecord on a supported Linux host rather than interpreting a browser connection as stronger capture.

Repository replay is native-session evidence by design

agentsight vis is the clearest example of why “no eBPF” does not mean “no useful evidence.” It scans matching local Claude, Codex, and Gemini sessions and reconstructs an ordered repository trajectory. That is enough to show where an agent moved through a worktree, which native file actions it recorded, and how activity changed over time. It is particularly useful when the run already happened and no recorder was active.

The evidence model is deliberately bounded. A native Tool action describes what the agent recorded it invoked; optional system observations can independently describe low-level effects; only session semantic content can answer why an action was chosen. For a deeper treatment of that boundary, see the Agent Nebula replay methods guide.

`report` can mix evidence classes, so provenance matters

Some reports operate on an AgentSight SQLite recording, while others can summarize local agent sessions. The README exposes agentsight report --local for native Claude/Codex/Gemini history and lets token reporting fall back to local agent sessions when appropriate. A saved record database, by contrast, can contain system capture and reconstructed model activity.

Do not collapse those sources into one trust level. AgentSight carries provenance such as native-session, direct-view, SQLite reconstruction, and legacy/unknown lineage in its audit model. If you are comparing or exporting evidence, preserve that source rather than treating every row as if it came from a kernel probe. The audit provenance guide explains the current confidence and lineage semantics.

What requires eBPF today

The documented boundary is straightforward: record and the eBPF-backed debug commands are Linux capture workflows. The usage guide says commands that load eBPF probes should run with sudo, withtop as the notable command that can remain useful without it. record starts the normal durable capture path with SSL, process, system, and web-view collection and saves an AgentSight SQLite session for later reporting.

# No eBPF required for the native-session path
agentsight top
agentsight report --local
agentsight vis
agentsight bind

# Linux system-boundary recording
sudo agentsight record -- claude

# Advanced eBPF-backed debug capture
sudo agentsight debug trace --server -c claude
sudo agentsight debug ssl --http-parser

Use the evidence question to choose the mode

Question	Start with	Why
Which local agent sessions exist and what tokens/models did they report?	Native `top` or `report --local`	The agent already persisted the relevant session facts.
How did an existing coding run move through this repository?	`vis`	Repository replay is designed around ordered native Tool/file actions.
I want to browse native history from another browser.	`bind`	Binding presents local evidence; it does not require probe loading.
Which child processes and low-level file effects actually occurred during this run?	`record`	Independent system-boundary evidence is the point of the Linux capture path.
What plaintext model traffic crossed a supported TLS/runtime boundary?	`record` or `debug ssl`	That evidence comes from runtime/system instrumentation rather than native transcript files.

No-eBPF mode is not a weaker version of the same dataset

The most common mistake is to think of native mode as “eBPF mode with fewer events.” It is better to see the two paths as different sensors. Native sessions are close to agent semantics and often contain model, tool, token, and conversation context that a system tracer would have to reconstruct. eBPF observation is independent of those agent logs and is better at real process, file, network, and runtime effects. Each source can be stronger for a different question.

That is the same system-boundary principle behind AgentSight more broadly: use native telemetry where it is authoritative, use independent observation where the run crosses process or system boundaries, and keep the lineage visible when the two are correlated. The broader comparison is in Why AI agent observability needs a system boundary.

Practical platform guidance

On macOS and Windows, start with the native-session commands because the README explicitly supportstop, bind, vis, and report from agent-native files. On Linux, the same commands work without granting eBPF privilege, while top can take advantage of richer capture when sudo is already available. Move to record when your question requires independent system evidence and the host can safely grant the required Linux tracing privilege.

If the data will leave the machine, review the evidence first. Native session history can include prompts, responses, repository paths, tool results, and other sensitive development context; recorded system data can include paths, network targets, headers, or payload material. The security and data handling page is the right boundary before sharing either form.