docs(observability): clarify runtime log sources and retention limits

Remove Docker copy guidance for the live supervisor tmpfs mount while retaining the Podman example. Distinguish sandbox-runtime security events from supervisor JSONL and gateway log streams, and qualify independent three-file retention.

Validation: mise run docs, Markdown lint, and git diff --check passed. Fern reported the same three existing unrelated warnings.
Signed-off-by: Matthew Grossman <mgrossman@nvidia.com>

Author: matthewgrossman

docs/observability/accessing-logs.mdx

@@ -6,7 +6,7 @@ description: "How to view sandbox logs through the CLI, TUI, supervisor files, a
 keywords: "Generative AI, Cybersecurity, Logging, CLI, TUI, Observability"
 ---
 
-Use the CLI or TUI for recent supervisor logs, and compute-driver tooling for supervisor files and main process output. The supervisor runs separately from the sandbox workload, so these logs have different locations and collection paths.
+Use the CLI or TUI for recent supervisor logs, and compute-driver tooling for supervisor files, sandbox-runtime events, and main process output. The supervisor runs separately from the sandbox workload, so these logs have different locations and collection paths.
 
 ## CLI
 
@@ -35,14 +35,16 @@ The TUI dashboard displays sandbox logs in real time. Logs appear in the log pan
 
 ## Main Process Output
 
-The sandbox's main process writes its stdout and stderr to the sandbox container's stdout and stderr, alongside warnings from the sandbox runtime. Read it with the container tooling for the compute driver:
+The sandbox's main process writes its stdout and stderr to the sandbox container's stdout and stderr, alongside sandbox-runtime diagnostics. Read this output with the container tooling for the compute driver:
 
 ```shell
 kubectl -n <namespace> logs <sandbox-pod> -c agent
 docker logs <sandbox-container>
 podman logs <sandbox-container>
 ```
 
+The sandbox runtime also emits OCSF shorthand events, including process-launch and Landlock filesystem events, into these container logs when its diagnostic log filter permits them. These runtime-originated events are not pushed to the gateway log stream or included in the supervisor's JSONL file. Collect workload container logs separately from supervisor logs to retain both sources.
+
 A main process started with a TTY writes only to its attachment; use `openshell sandbox connect` to view that output. Output from `sandbox exec` and SSH sessions does not reach the container log, and `openshell logs` does not include main process output.
 
 When the container runtime falls behind reading the log, the main process blocks on writes, as with any container.
@@ -51,7 +53,7 @@ When the container runtime falls behind reading the log, the main process blocks
 
 The supervisor pushes logs to the gateway over gRPC in real time. The gateway stores up to 2,000 recent log lines per sandbox in memory. This buffer is not persisted to disk and is lost when the gateway restarts or the sandbox's buffers are removed. The push channel is bounded and can drop events under load or during disconnection.
 
-For durable retention, collect supervisor output or files into an external log store. The local files rotate and use temporary storage on container drivers; they are not a durable archive. See [Direct Filesystem Access](#direct-filesystem-access) for locations and collection limits, and [OCSF JSON export](/observability/ocsf-json-export) for structured file output.
+For durable retention, collect supervisor output or files and workload container logs into an external log store. The local files rotate and use temporary storage on container drivers; they are not a durable archive. See [Direct Filesystem Access](#direct-filesystem-access) for locations and collection limits, and [OCSF JSON export](/observability/ocsf-json-export) for structured file output.
 
 The gateway's separate `ocsf_log` configuration writes gateway-produced OCSF events to JSONL. It does not persist supervisor log lines received over gRPC or main process output.
 
@@ -85,15 +87,15 @@ The supervisor writes shorthand logs to `/var/log/openshell.YYYY-MM-DD.log` and,
 | VM | `/var/log` on the host running the supervisor, if writable | Host-managed storage. The driver also captures stderr in `supervisor.err.log` in the sandbox's driver state directory. |
 | Windows MXC | Gateway-local JSONL output | See [Windows MXC gateways](/observability/ocsf-json-export#windows-mxc-gateways). |
 
-Use platform tooling with access to the supervisor resources. For example, copy the current Docker or Podman supervisor files to a local directory while the container is running:
+Use platform tooling with access to the supervisor resources. For Podman, copy the current supervisor files to a local directory while the container is running:
 
 ```shell
 mkdir -p ./supervisor-logs
-docker cp <supervisor-container>:/var/log/. ./supervisor-logs/
-# For Podman, use this instead.
 podman cp <supervisor-container>:/var/log/. ./supervisor-logs/
 ```
 
+Docker's `docker cp` cannot copy the live contents of the supervisor's tmpfs log mount. Retrieving those files requires operator-managed access to the live mount on the Docker daemon host. The default supervisor image has no shell or `tar`, so shell-based `docker exec` collection is not an alternative.
+
 For live shorthand output, read the supervisor's stderr through the platform log interface:
 
 ```shell
@@ -102,7 +104,7 @@ docker logs --follow <supervisor-container>
 podman logs --follow <supervisor-container>
 ```
 
-This console output follows the supervisor's diagnostic log filter and does not include full OCSF JSON records. A cluster or container log collector can ship it for retention. Collect workload container logs separately for main process output.
+This console output follows the supervisor's diagnostic log filter and does not include full OCSF JSON records. A cluster or container log collector can ship it for retention. Collect workload container logs separately for main process output and sandbox-runtime events.
 
 The default supervisor image has no shell or `tar`, so shell-based `kubectl exec` and `kubectl cp` examples do not work with that image. Reading Kubernetes supervisor files requires operator-managed access to its log volume, such as cluster debugging tooling. OpenShell does not configure a file collector for you.
 

docs/observability/logging.mdx

@@ -236,6 +236,8 @@ For L7 REST policy denials, the body also includes structured policy fields such
 
 Landlock filesystem restrictions emit `CONFIG:` events at startup and whenever the sandbox has to skip a requested path.
 
+These events originate in the sandbox runtime and appear in [workload container logs](/observability/accessing-logs#main-process-output) when the runtime's diagnostic log filter permits them. They are not included in the supervisor's JSONL file or pushed to the gateway log stream.
+
 On startup, the probe reports the kernel's supported Landlock ABI version alongside the requested path counts:
 
 ```text
@@ -258,10 +260,12 @@ The supervisor writes logs to `/var/log/` in its own filesystem, separate from t
 
 | File | Format | Rotation |
 |---|---|---|
-| `openshell.YYYY-MM-DD.log` | Shorthand + standard tracing | Daily, 3 files max |
-| `openshell-ocsf.YYYY-MM-DD.log` | OCSF JSONL when enabled | Daily, 3 files max |
+| `openshell.YYYY-MM-DD.log` | Shorthand + standard tracing | Daily |
+| `openshell-ocsf.YYYY-MM-DD.log` | OCSF JSONL when enabled | Daily |
+
+Each supervisor file appender is configured with a three-file limit. The shorthand appender's filename prefix also matches JSONL files, so its cleanup can delete JSONL history on filesystems that expose file creation timestamps. Do not rely on independent three-file retention for each format.
 
-Both files rotate daily and retain the 3 most recent files to bound disk usage. File output requires a writable `/var/log` and uses non-blocking writers that can drop events under pressure. If file logging cannot start, the supervisor falls back to stderr-only output.
+File output requires a writable `/var/log` and uses non-blocking writers that can drop events under pressure. If file logging cannot start, the supervisor falls back to stderr-only output.
 
 Docker and Podman use tmpfs for this directory; Kubernetes uses an `emptyDir` in the supervisor pod. Collect logs externally before rotation or teardown for durable retention. See [Accessing Logs](/observability/accessing-logs#direct-filesystem-access) for driver-specific access and storage lifetimes.
 

docs/observability/ocsf-json-export.mdx

@@ -71,7 +71,9 @@ do not suppress records in this explicitly enabled audit sink.
 
 For sandbox supervisors, OCSF JSON records are written to `/var/log/openshell-ocsf.YYYY-MM-DD.log` in the supervisor's filesystem, separate from the workload. `openshell sandbox exec` cannot read those files. File output requires a writable `/var/log`; if the supervisor falls back to stderr-only logging, enabling `ocsf_json_enabled` does not create a JSONL sink.
 
-Supervisor files rotate daily and retain the three most recent files. Docker and Podman store them on tmpfs; Kubernetes stores them in the supervisor pod's `emptyDir`. For durable retention, arrange external collection before rotation or teardown. See [supervisor file access](/observability/accessing-logs#direct-filesystem-access) for collection paths and best-effort limits.
+This file contains supervisor-originated events, not the [sandbox-runtime events](/observability/accessing-logs#main-process-output) emitted into workload container logs.
+
+Supervisor files rotate daily with a configured three-file limit, but cleanup can remove JSONL history earlier. See [supervisor file retention](/observability/logging#log-file-location) for the limits. Docker and Podman store them on tmpfs; Kubernetes stores them in the supervisor pod's `emptyDir`. For durable retention, arrange external collection before rotation or teardown. See [supervisor file access](/observability/accessing-logs#direct-filesystem-access) for collection paths and best-effort limits.
 
 Windows MXC gateway records use `%PROGRAMDATA%\OpenShell\logs` or `OPENSHELL_OCSF_LOG_DIR`. That sink also rotates daily and retains the three most recent files. The separate `[openshell.gateway.ocsf_log]` sink uses its configured path and retention.