What the analysis could not settle from the code alone.
SKILL.md documents OLLAMA_HOST as a free-form URL (e.g. http://your-ollama-host:11434); if it is pointed at a remote host, ollama_generate sends conversation prompts there — no validation or allowlisting of OLLAMA_HOST values is shown in the instruction text.
Data exfiltration
DET:61c05e22c22aef56 cites the string 'id_ed25519' at src/modules/mount-security/index.ts:81, but that excerpt is not visible in the decoded view of this file shown here; confirm whether it is an entry in DEFAULT_BLOCKED_PATTERNS (defensive blocklisting of SSH key paths from mounts) rather than a credential read.
Credential access
DET:4765819d19fec61d cites a file_read of '/workspace/agent/CLAUDE.md' at src/provider-contracts/claude.ts:15, which is outside the shown span (lines 37-83); confirm whether this is the host composing/reading the project document it owns (benign) or access to agent configuration beyond the declared task.
Credential access
DET:4fc6dda7f8cd3f32 cites a read of '/root/.npmrc' at container/install-cli-tools.sh:20; that file is not in this batch. Confirm whether the npm config read is benign tool installation setup or accesses registry credentials that then leave the host.
Credential access
DET:4b3c1fb99357dfd0 cites unrestricted process.env access at src/container-runner.ts:1135; that file is not in this batch. Confirm which environment variables are read and whether any credential value is threaded into containers or sent off-host.
Credential access
Does container/agent-runner/src/provider-contracts/realize.ts read environment variables beyond declared passthrough and pass any value to a network or storage sink?
Credential access
Does src/drivers/index.ts read process.env only for driver configuration, or does any value reach a credential or network sink?
Credential access
Does the allowlisted-extra pinning class applied to in-tree provider mount contributions (defined in src/drivers/types.ts) skip user approval for extra mounts that a skill-registered provider contributes?
Privilege escalation
None of the units shown implements the declared ollama_list_models/ollama_generate/ollama_pull_model/ollama_delete_model/ollama_show_model/ollama_list_running tools; whether the modules barrel (../modules/index.js) loads an Ollama tool module, and whether that module registers anything beyond the declared tools or calls extendTool on base tools, cannot be verified from this batch.
Tool poisoning
Whether the host-side delivery enforcement (src delivery.ts via the agent_destinations table) restricts which destinations or files send_file may deliver is asserted in comments but not shown, so the reach of the file-egress channel is undetermined.
Data exfiltration
The modules barrel comment says mailbox skills replace mailbox/compose.ts — can skills override runner source modules, and does this target exercise that replacement?
Supply chain
MODULE-HOOK:scheduling-pre-task markers imply a module injection step that fills the scheduling hook block at build or load time; which module supplies it and what code can it inject?
Code execution
All units in this batch come from container/agent-runner rather than the declared skill root .claude/skills/add-ollama-tool; confirm whether the skill invokes or ships this runner code.
readProviderTrace/newestClaudeTranscript feed a '/upload-trace' flow whose destination and handler are not in these units; whether transcript content leaves the host cannot be settled from this evidence.
Data exfiltration
The comment claims NanoClaw's container isolation and the OneCLI allow-list are the security boundary that makes bypassPermissions acceptable; that boundary is not verifiable from the units shown.
Privilege escalation
R21/C5: the cited 'network echo.ai' line is an echoed documentation URL (echo of build instructions), not an outbound request; no code in this batch contacts echo.ai and its status as the project's genuine publisher domain is unverifiable here — does any executed or fetched build code (pull.sh, Dockerfile, pnpm config) contact echo.ai?
Data exfiltration
R20: the detector reports file_read of $PROJECT_ROOT/.env.bak, but the cited line is 'rm -f' deleting the backup that 'sed -i.bak' just created on the previous line; no read of .env.bak is visible — confirm no other build step reads .env.bak.
Credential access
R23: the detector reports file_read of /root/.npmrc, but the cited code writes /root/.npmrc (writeFileSync of pnpm only-built-dependencies opt-ins) and never reads npm auth from it — confirm nothing else in the install flow reads credentials from /root/.npmrc.
Credential access
Where do task messages' script fields originate (host API, channel messages, peer agents)? This batch does not show the writer, so the reach of the runScript bash-execution sink cannot be established.
Code execution
The owed units for the add-ollama-tool skill contain no Ollama-specific code (only container-orchestration, DB, and messaging-host modules); whether the skill actually exercises these host modules, or only the declared Ollama MCP tools whose metadata units live in other batches, cannot be settled from this batch.
All 118 units in this batch are host db/migration/session/driver plumbing (messaging groups, approvals, migration runner, driver registry) with no Ollama- or MCP-related content, while the declared target is the add-ollama-tool skill; confirm whether these src/db and src/drivers files are actually consumed by the skill (which would make them large undeclared surface) or are unrelated repository context served with the batch.
Detector lead DET:3f1e60c3868e150e (RX-HIJACK-SECRECY, excerpt 'silently run') was checked against SRC:14ea2872d2b35661 and does not hold: the matched phrase is 'a host configured for one runtime that would otherwise silently run another', a rationale for rejecting driver fallbacks, not an instruction to act without the user's knowledge; confirm no other view of src/drivers/index.ts contains an actual secrecy directive.
Agent hijacking
The declared purpose is adding an Ollama MCP server, but every unit in this batch is host-runtime framework code (docker session driver selection, egress lockdown via the container CLI, gateway-provider approval registry, .env parsing, mount/credential validation) with no Ollama-specific logic; whether this framework is payload the skill ships and patches, or repository context outside the skill's payload, cannot be settled from the units shown.
Do residue items R10-R17 (file_read of .ssh, .gnupg, .aws, .netrc, .npmrc, .pypirc, id_rsa, id_ed25519) describe real credential reads? The cited literals are entries of DEFAULT_BLOCKED_PATTERNS, a mount denylist that rejects these host paths, so the claimed reads appear refuted; please confirm the detector classification is a false positive.
Credential access
Does residue R19 (file_read '/workspace/agent/CLAUDE.md') describe a real file read? The literal is a containerPath declaration in the Claude provider contract naming where the composed document is mounted inside the container, so the read appears refuted.
Credential access
Does the add-ollama-tool skill actually consume or modify the shipped NanoClaw src/ framework files (mount-security, typing, provider-contracts, project-doc-compose) shown in this batch, or are they unrelated repository content, given the target declares only adding an Ollama MCP server?
Whether the NanoClaw gateway whose CA is trusted into Chromium's NSS store is operator-controlled only, or whether its CA material can be influenced by a third party, which would make the trust-store import a MITM foothold rather than a functional requirement.
Persistence
What does trustGatewayCaForChromium write (which NSS/trust-store files inside the container) and where does the gateway CA certificate it installs come from?
Persistence
poll-loop.ts mentions running pre-task scripts for tasks such as monitoring crons; where do these scripts originate and what can they execute?
Code execution
Does the host router actually restrict /upload-trace to authorized operators before it reaches the container runner, as the comment claims?
Data exfiltration
Which inbound messages does categorizeMessage classify as passthrough/admin and pass raw to the SDK as native slash commands, and can a channel message trigger them?
Code execution
What does the OneCLI allow-list constrain in practice, given the agent runs with bypassPermissions and wildcard mcp__*__* allowedTools for every registered MCP server?
Privilege escalation
Who authors the task messages whose content.script field the container executes, and can an untrusted channel participant inject one?
Code execution
Is the claimed host-side admin gate on the /upload-trace command actually enforced before a message matching the command reaches the container?
Data exfiltration
Under what condition does build.sh reach the branch that rewrites NANOCLAW_HARDENED_IMAGE=false in the host .env, and can a skill cause that branch to run?
Persistence
What does the add-ollama-tool skill itself add to cli-tools.json or the Dockerfile, and does it instruct running container/build.sh (host-side rebuild with root-level installs) to apply the change?
Supply chain
Detector lead DET:cf0a5d82dc89a702 flags an EXFIL claim-contradiction ('Ollama runs locally and is keyless...') against src/config.ts:136, but that claim text does not appear in the shown unit, whose only content is local env-var validation via net.isIP with a 127.0.0.1 default and no network send; where does the claimed keyless/local Ollama statement live and does any Ollama path send data off-host?
Data exfiltration
Detector lead DET:3e94bf2295c4c523 classifies '/workspace/agent/CLAUDE.md' as a host_config_write, but the shown code mounts it read-only into the container from the group's data directory; confirm no host-side persistence write exists for this path outside the app's own composed project document.
Persistence
DET:3f1e60c3868e150e (HIJACK 'silently run') on src/drivers/index.ts:21 does not confirm: the phrase refers to a host that would 'otherwise silently run another' runtime driver due to fallback selection, and the code's stated design throws instead of falling back; it is not an instruction to act without the user's knowledge.
DET:3e328c1be01792db (CRED process.env) on src/drivers/index.ts:68 does not confirm as credential access: readSetting is typed to only the two NANOCLAW_RUNTIME_DRIVER / NANOCLAW_SESSION_MATERIAL_ROOT config keys, not arbitrary env or secrets.
No unit in this batch references Ollama, MCP server installation, or the declared add-ollama-tool capability; the shown units are host-internal DB and driver-selection code, so the link between the declared skill purpose and these files is not established by the evidence shown.
updateMessagingGroup, updateMessagingGroupAgent, and updateSession interpolate update object keys directly into SET clauses without the runtime column allowlist that updateContainerConfigScalars/updateContainerConfigJson apply; is any untrusted external content ever routed into these update objects at a callsite?
The declared target is the 'add-ollama-tool' skill providing Ollama MCP tools, but every unit in this batch is host-side infrastructure (provider-contract validators, provider container registry, session manager, reconcile feeds, timezone helpers, DB type comments) with no reference to Ollama, MCP servers, or the skill directory; confirm whether this content actually belongs to the declared skill artifact or is unrelated repository context.
extractAttachmentFiles, readOutboxFiles, and clearOutbox rely on AnchoredDir.open and isSafeAttachmentName/inboxFolderName/deriveAttachmentName, whose implementations are not in the shown lines; do these helpers actually enforce the described basename checks and symlink refusal, so the base64-decode-to-inbox-write chain cannot escape the session directory?
[invalid file request] How is the Ollama base URL resolved (OLLAMA_HOST default and localhost fallback), and are ollama_pull_model/ollama_delete_model/ollama_show_model/ollama_list_running registered only when OLLAMA_ADMIN_TOOLS=true as the comments claim?
Data exfiltration
[file request container/CLAUDE.md] This file is cited by SRC:84a50405ef7a851e ('container/CLAUDE.md is the canon') and SRC:1e2534e1bd6b1e5a as the core-owned canonical instruction template rendered into every agent's project document, i.e. text the agent will read. Does it contain directives that override agent instructions, demand secrecy, or steer beyond the declared task?
Agent hijacking
[file request container/build.sh] The skill instructs running ./container/build.sh after its code edits and in troubleshooting; what does this unshown build script execute, and does it run anything beyond rebuilding the container image?
Code execution
[file request container/agent-runner/src/memory/hook.ts] What does the SessionStart hook command 'bun /app/src/memory/hook.ts' read, write, or fetch over the network when it runs at session start?
Persistence
[file request container/agent-runner/src/mailbox/index.ts] Which mailbox implementation registers as the agent mailbox, and where do outbound message rows (including decorated system-action payloads) physically leave the container (socket, database, HTTP endpoint)?
Data exfiltration
[file request src/index.ts] Does host startup call initDb with a url-bearing DbConfig or install a non-SQLite/remote database driver via the composition barrel?
Data exfiltration
[file request .env.example] Which env vars are declared in .env.example, and do any carry credentials or reachable host URLs beyond the documented Ollama block?
Credential access
[file request container/pull.sh] Which registry and reference does pull.sh fetch the agent image from, and is the reference pinned or digest-verified before it is retagged locally?
Supply chain
[file request src/providers/index.ts] Which provider host-adapter functions consume context.hostEnv (process.env), and can any of them copy host environment values into contribution.env, mounts, or auxiliary-container config that reaches the agent container?
Credential access
[file request src/drivers/docker-driver.ts] How does DockerSessionDriver construct the container invocation (command, mounts, env, network args), and does any secret, host file, or session payload reach the container or an external sink?
Code execution