The command name is not necessarily the executable
A CLI entry point can be a symlink, shell wrapper, JavaScript file with a Node shebang, or container launcher. AgentSight record follows PATH resolution, symlinks, and shebang interpreters so the capture can target the runtime that actually owns the process and TLS code. This matters before any eBPF detail: attaching perfectly to the wrong binary still produces an empty or misleading trace.
Follow the process family instead of one PID
Coding agents routinely spawn shells, package managers, compilers, tests, language servers, browsers, and MCP servers. The parent CLI is therefore only the root of the investigation. Use process-family context to attribute descendant activity back to the selected run while keeping the recording bounded enough that unrelated workstation activity does not dominate the result.
TLS compatibility depends on the runtime and binary build
The easy case is a dynamically linked OpenSSL client with usable SSL_read and SSL_write symbols. Modern CLIs can instead embed OpenSSL in Node, statically link stripped BoringSSL through Bun, or use rustls. AgentSight v1.0.3 has compatibility paths for several of these cases, including byte-pattern and offset discovery, but those fingerprints are version-sensitive. Empty TLS capture should trigger binary and TLS-stack diagnosis, not a blanket conclusion that eBPF failed.
Thread filters can silently hide the traffic you wanted
The kernel comm name of the thread doing TLS work can differ from the CLI name. AgentSight documents Claude Code as a concrete example: model traffic is handled by an internal HTTP Client thread. When an explicit binary path is used, AgentSight avoids applying the process-name filter to SSL monitoring so the relevant worker thread is not discarded, while process monitoring can remain scoped to the agent command.
Containers require descendant executable discovery
Container metadata often identifies an init process such as tini rather than the Node or other runtime that owns TLS. AgentSight docker:// and k8s:// resolution walks from the container host PID toward descendants and selects an SSL-embedding executable when supported. This is a compatibility layer, not proof that every container topology or runtime will resolve identically; verify the resolved binary on a representative run.
System observation does not reconstruct private intent
A process tracer can show that a child command ran, a path was touched, or a destination was contacted. It does not automatically know why the model chose that action, which internal policy allowed it, or how the agent labeled the tool call. When native telemetry exists, keep it for intent and policy semantics and add AgentSight when the investigation crosses into uninstrumented descendants or host effects.
$ command -v <agent> && readlink -f "$(command -v <agent>)"
$ sudo agentsight record -- <agent-command>
$ sudo agentsight debug ssl --binary-path <resolved-binary> --verbose