nono audit list should surface nested tool-sandbox activity

[lukehinds]

What problem are you trying to solve?

command_policies tool executions are correctly recorded as command-policy
events in the outer supervised session, but nono audit list only displays the
outer command. This makes a successful tool-sandbox enforcement decision look
as though it was not audited.

For example, consider a profile that mediates gh, permits read-only GitHub
operations, and denies mutations. An agent is asked to post an issue comment,
and nono correctly blocks:

gh issue comment 1052 --repo nolabs-ai/nono --body hello

Afterwards, nono audit list displays only the outer Claude session:

nono 1 command(s)

  ~/dev/nono-workspace/tool-sandbox-package/github-cli (1 command)
    4a5676ab022fb69c  5m ago  completed  claude 'Use gh to post a comment...'

From this output alone, an operator cannot tell that:

• tool-sandbox mediation was active;
• gh was invoked;
• a read-only gh operation was allowed; or
• the mutating gh issue comment operation was denied.

The audit data is not missing. nono audit show 4a5676ab022fb69c correctly
shows the command-policy events:

Command Policy Events: 3
  invocation_allowed gh caller=session
  allowed gh caller=session
  invocation_denied gh caller=session reason=agents may read issues but not comment on them

The session's audit chain, Merkle root, and ledger entry also verify. The issue
is discoverability in the list view, not enforcement or audit integrity.

What would you like to see?

Surface a compact tool-sandbox summary alongside each outer session in
nono audit list. For example:

nono 1 session(s)

  ~/dev/nono-workspace/tool-sandbox-package/github-cli (1 session)
    4a5676ab022fb69c  5m ago  completed  claude 'Use gh to post a comment...'
      tools: gh (1 allowed, 1 denied)

This should remain one audit session. Tool invocations are causally part of the
outer supervised run and should continue to be integrity-covered events within
that session rather than separate top-level sessions.

Possible CLI designs include:

• showing the compact tool summary by default;
• adding an opt-in --include-tools/--tools list mode if reading event logs
  for every session would make the default view too expensive; or
• persisting a denormalized command-policy summary in finalized session
  metadata so the default list remains cheap.

The JSON list output should expose equivalent structured data, for example:

{
  "tool_sandbox_active": true,
  "command_policy_event_count": 3,
  "tool_commands": [
    {
      "command": "gh",
      "allowed": 1,
      "denied": 1
    }
  ]
}

The exact JSON shape is open for discussion.

Acceptance criteria

• nono audit list can indicate that a session contains tool-sandbox command
  policy activity without requiring the operator to guess and run audit show.
• The summary identifies mediated command names and makes denials prominent.
• Lifecycle events are not misleadingly counted as separate executions. For
  example, invocation_allowed followed by terminal allowed for the same
  shim request represents one allowed invocation.
• nono audit list --json exposes the same information in structured form.
• The existing detailed and redacted command-policy records remain available
  through nono audit show <session-id> and --json.
• Tool invocations remain events within the parent session; no duplicate
  top-level audit sessions or ledger entries are created.
• Existing audit verification and redaction guarantees are preserved.
• Sessions without tool-sandbox activity retain a concise list display.

What have you tried instead?

The current workaround is to inspect each candidate session individually:

nono audit show <session-id>
nono audit show <session-id> --json
nono audit verify <session-id>

This works for a known session ID but does not scale well when reviewing many
agent runs or looking specifically for denied tool operations.

Additional context

Today cmd_list renders only SessionMetadata.command, while cmd_show reads
CommandPolicy events from the session's audit-events.ndjson. The underlying
event model already contains the required command, caller, decision, reason,
redacted argv, hashes, process attribution, exit code, and stdio accounting.

Suggested labels: enhancement, audit, tool-sandbox, cli.

Priority: nice improvement with a working per-session workaround.

[nogent-nolabs-ai]

🛡️ nogent issue triage

Assessment: needs-code-change

Suggested resolution: Modify the CLI audit list command implementation in crates/nono-cli (likely in its audit or CLI command-handling modules) to extract tool execution stats (either by reading the session's event log or appending denormalized summary data to the session metadata) and update the text/JSON formatting structures.

Notes for maintainers: This is a feature enhancement requiring Rust code changes in crates/nono-cli. As noted in the issue, reading audit-events.ndjson for every session might degrade listing performance; a design decision is needed on whether to denormalize basic tool counts directly into the session metadata when the tool execution concludes, or read events on demand (optionally behind a flag like --include-tools). Ensure all redaction rules remain applied to any displayed tool command metadata.

_{Automated triage suggestion. Not a maintainer decision.}