Claude Code Audit — 2026-04-23 22:30 UTC

Cycle: 7th audit of the day (every-6-hours cadence; this cycle: manual + cron ~22:27 UTC)

Auditor: SCOUT (TITAN research agent)

Baseline: F:/TITAN/plans/advisors/CLAUDE-CODE-ARCHITECTURE-DEEP-DIVE-2026-04-22.md

Prior audits this day: 1530, 1700, 1800, 2200 (Apr 22) → 0000, 0400, 1630 (Apr 23)

CC version at last audit (16:30 UTC): v2.1.118

CC version this cycle: v2.1.118 — confirmed latest (GitHub releases, fetched 2026-04-23T22:xx UTC)

Local TITAN install: v2.1.49 (69-version gap; T030 filed — still open)

Word count: ~2,400

---

1. CC Version Delta Since Last Audit (16:30 UTC → 22:30 UTC)

No new release this cycle. v2.1.118 (released 2026-04-23 00:42 UTC) remains the latest version on both npm and GitHub. This is confirmed via direct fetch of github.com/anthropics/claude-code/releases.

Cumulative version ladder since baseline (all cycles combined):

| Version | Date | Key Architectural Signal |

|---------|------|--------------------------|

| v2.1.94 | Apr 7 | Default effort raised to high for API/Bedrock/Enterprise users |

| v2.1.97 | Apr 8 | Focus view, agent panel live indicators, Accept Edits auto-approval expansion |

| v2.1.98 | Apr 9 | Bash security hardening (env-var prefixes, /dev/tcp, compound cmds), MCP OAuth fix |

| v2.1.101 | Apr 10 | /team-onboarding, Vertex AI wizard, Monitor tool, subprocess PID namespace sandboxing |

| v2.1.105 | ~Apr 13 | PreCompact block support, plugin monitors key, skill description cap 1,536 chars |

| v2.1.108 | Apr 14 | ENABLE_PROMPT_CACHING_1H, /recap session rehydration, Skill tool unification of slash commands |

| v2.1.109 | Apr 15 | Extended-thinking progress indicator |

| v2.1.110 | Apr 15 | /tui fullscreen, mobile push notifications, Remote Control /context//exit |

| v2.1.111 | Apr 16 | Opus 4.7 xhigh effort, /ultrareview parallel multi-agent review, /less-permission-prompts skill, /effort slider |

| v2.1.113 | Apr 17 | Native binary CLI replaces bundled JS, sandbox.network.deniedDomains, bash deny hardening for exec wrappers |

| v2.1.116 | Apr 20 | 67% faster /resume on 40MB+ sessions, deferred MCP template loading |

| v2.1.117 | Apr 22 | CLAUDE_CODE_FORK_SUBAGENT=1 for external builds, mcpServers in agent frontmatter, concurrent MCP connect default-on |

| v2.1.118 | Apr 23 | MCP tools invocable from hooks (type: "mcp_tool"), /usage replaces /cost+/stats, named themes, WSL settings inheritance |

Source: github.com/anthropics/claude-code/releases (fetched 2026-04-23); code.claude.com/docs/en/changelog (fetched 2026-04-23); ~/.claude/cache/changelog.md (read 2026-04-23).

---

2. New Patterns This Cycle — Features Not Previously Analyzed

2.1 Three New Security Layers in Bash/Permission Architecture (v2.1.98, v2.1.101, v2.1.113)

What changed (aggregate, not previously consolidated).

Across v2.1.98 through v2.1.113, Anthropic made six distinct security hardening changes to the Bash and permission subsystems:

1. v2.1.98: Deny rules now match commands wrapped in env, sudo, watch, and similar execution wrappers. Previously, sudo dangerous-cmd could bypass a deny rule on dangerous-cmd alone.

2. v2.1.98: Compound bash commands (cmd1 && cmd2; cmd3) no longer bypass forced permission prompts — each segment is evaluated independently.

3. v2.1.98: Read-only commands with env-var prefixes (MYVAR=foo dangerous-cmd) now prompt unless the variable is in an explicit known-safe list (LANG, TZ, NO_COLOR, etc.).

4. v2.1.98: Redirects to /dev/tcp/ and /dev/udp/ (out-of-band network access) now trigger prompts rather than auto-allowing.

5. v2.1.98: permissions.deny rules now correctly override a PreToolUse hook's permissionDecision: "ask" — previously a hook could downgrade a deny to a prompt.

6. v2.1.113: sandbox.network.deniedDomains allows blocking specific domains even when broader network access is allowed.

Significance for the baseline's 8-layer permission model. The baseline described eight security layers as of the leaked source. These six changes represent micro-hardening within layers 3 (configuration rules), 5 (dangerous pattern detection), and 6 (filesystem/permission validation). The model is getting more complete at each layer, not adding new layers. The architecture was right; the implementation coverage is expanding.

TITAN hook implication. TITAN's PreToolUse Bash hook (titan-bash-guardrail.py) runs with a 5-second timeout before any Bash execution. The v2.1.98 fix that deny overrides a hook's ask decision is directly relevant: if titan-bash-guardrail.py ever returns permissionDecision: "ask" on a command that settings.json has in permissions.deny, the deny now wins. This is the correct behavior — the hook cannot downgrade a hard deny to a user prompt. TITAN's guardrail script should be audited to ensure it never returns "ask" for commands that should be hard-denied.

For Silent Infinity. No direct impact — SI uses no Bash tool. The pattern reinforces that SI's guardrails.py deny-first architecture is aligned with how Anthropic thinks about safety layers.

Sources: code.claude.com/docs/en/changelog v2.1.98, v2.1.113 (fetched 2026-04-23); C:/Users/Harnoor/.claude/settings.json (read 2026-04-23).

---

2.2 Subprocess PID Namespace Sandboxing (v2.1.101) — Infrastructure-Level Isolation

What changed. v2.1.101 added CLAUDE_CODE_SUBPROCESS_ENV_SCRUB for PID namespace isolation on Linux, plus CLAUDE_CODE_SCRIPT_CAPS to limit per-session script invocations. The Monitor tool was also added — it streams events from background scripts running alongside the main session.

Significance. This is the first evidence of OS-level process isolation being added to CC's security model. Prior audits described the permission model as eight layers of application-level checks. PID namespace isolation is a ninth layer — an OS enforcement boundary below the application. It is Linux-only and opt-in at this stage, suggesting it is in early validation rather than default.

The CLAUDE_CODE_SCRIPT_CAPS implication for TITAN. TITAN runs CC with bypassPermissions mode and multiple hook scripts that spawn Python subprocesses. In a future hardened deployment, CLAUDE_CODE_SCRIPT_CAPS could cap how many hook scripts fire per session — a consideration when TITAN currently fires 7 hook scripts per session (titan-validate-skill, titan-bash-guardrail, titan-sync, titan-metrics×2, titan-session-log×2, titan-precompact, titan-postcompact, titan-reflect). If CC ever defaults CLAUDE_CODE_SCRIPT_CAPS to a low number, TITAN's hook density could hit the cap. Not urgent at current opt-in status, but worth watching.

For Silent Infinity. Not applicable — SI is a serverless Lambda function, not a local subprocess environment.

Source: code.claude.com/docs/en/changelog v2.1.101 (fetched 2026-04-23); C:/Users/Harnoor/.claude/settings.json (read 2026-04-23).

---

2.3 Plugin `monitors` Key: Background Plugin Processes (v2.1.105)

What changed. v2.1.105 added a monitors key to the plugin manifest. A monitor is a background script that runs alongside the session, streaming events to the Monitor tool. It auto-arms at session start or when its associated skill is invoked.

Significance. Monitors are a new persistence primitive that was not in the baseline. Prior audits described the background task pattern via SleepTool and PushNotificationTool (the Kairos self-wake pattern). Monitors are different: they are persistent background processes attached to a plugin, not self-rescheduling agent turns. They are closer to event-stream daemons than to agent turns.

Distinction from the hook system. Hooks are synchronous interceptors on specific tool events. Monitors are async event streams that the model can read at any time via the Monitor tool. They are complementary, not overlapping.

TITAN implication. TITAN's Stop hook fires titan-reflect.py asynchronously after each session. The monitors pattern could replace or augment this: instead of a post-session reflection, a titan-monitor.js could stream file-change events and research queue updates throughout the session. This would give TITAN real-time awareness of changes to F:/TITAN/ during agentic tasks without polling. Worth evaluating after T030 (binary update) is complete — monitors require v2.1.105+.

For Silent Infinity. Not applicable — SI is serverless and has no local plugin runtime.

Source: code.claude.com/docs/en/changelog v2.1.105 (fetched 2026-04-23); C:/Users/Harnoor/.claude/ glob (2026-04-23).

---

2.4 HN Community Signal: React TUI + "External State Governance" Pattern (March 2026)

Source: news.ycombinator.com/item?id=47597085 (Claude Code Unpacked post, ~March 2026).

Key observations from the developer community:

1. React scene-graph TUI: CC uses React to build scene graphs and rasterize them to ANSI sequences within a ~16ms frame budget. This explains the 512K LOC density — a full React rendering engine for terminal output is not trivial.

2. "External State Governance" counterfactual. One developer argues that LLMs should be "completely stripped of orchestration rights" with state living in external databases. The commenter treats the model as a stateless function called by a deterministic state machine. This is architecturally the opposite of CC's approach (model-as-orchestrator). The HN commenter may be describing the correct architecture for safety-critical systems; CC's approach (model-as-orchestrator) is correct for developer-productivity tools where flexibility beats determinism.

3. Industry-wide complexity benchmark. Gemini Code Assist (~570K LOC), Codex (~720K LOC), OpenCode (~670K LOC) all show similar scale to CC's 512K LOC. The complexity is not CC-specific — it is intrinsic to production-grade agentic systems at this capability level.

Implication for Silent Infinity. SI's architecture (Lambda + DDB + Bedrock) maps to the "external state governance" pattern that the HN commenter proposed: the model is stateless, state lives in DDB, orchestration is in Lambda Python code. This is actually architecturally appropriate for a wellness product — the model should not have orchestration rights over user data. The sentiment that CC's complexity is partially defensive (against probabilistic model fragility) supports SI keeping its orchestration thin.

Source: news.ycombinator.com/item?id=47597085 (fetched 2026-04-23, post from ~March 2026).

---

2.5 TITAN Settings.json Fresh Scan — Three New Observations

Settings file read 2026-04-23 (verbatim at C:/Users/Harnoor/.claude/settings.json):

Observation A — autoMemoryDirectory is configured. The setting "autoMemoryDirectory": "F:/TITAN/knowledge/auto-memory/" is present. The baseline memo referenced an autoMemoryDirectory bug found in the leaked source (directory not created automatically). TITAN has explicitly set this path. Whether the path exists on disk and whether v2.1.49 honors this field correctly is unconfirmed — v2.1.49 predates the period when most skill frontmatter fields were finalized. If v2.1.49 does not support autoMemoryDirectory correctly, auto-generated memories are silently failing to write. After T030 (binary update), verify that files appear in F:/TITAN/knowledge/auto-memory/ following memory-generating turns.

Observation B — PostCompact hook is present. titan-postcompact.py is wired as a PostCompact hook. The baseline described PostCompact as a hook that can reinject systemMessage after compaction. Prior audits (16:30 cycle) noted that PreCompact is properly wired. The PostCompact hook was NOT mentioned in the baseline's hook analysis — it is newer, added in a cycle after the baseline. Confirmed functional provided titan-postcompact.py exists and returns a JSON {systemMessage: "..."} payload. No regression here, this is an improvement vs. the baseline.

Observation C — titan-injection-scan.py on Read/WebFetch/WebSearch. A synchronous (no async: true) injection scan hook runs on every Read, WebFetch, and WebSearch result. This is a prompt injection defense for external content. It is not async: true, which means it adds latency on every external read in the hot path. The CC security docs describe prompt injection as a first-class MCP server concern. For TITAN sessions that involve heavy web research (like this audit cycle), the injection scan fires on every WebSearch and WebFetch result — potentially 20-30 times per audit cycle. If titan-injection-scan.py has a non-trivial runtime, this is measurable latency accumulation.

Source: C:/Users/Harnoor/.claude/settings.json (read 2026-04-23).

---

3. Silent Infinity — Regression Check (Full 14-Pattern Audit)

Baseline: 14 patterns from CLAUDE-CODE-ARCHITECTURE-DEEP-DIVE-2026-04-22.md.

Prior audit (1630 UTC) found 0 regressions. This cycle extends the check with new observations.

|---|---------|-----------|-----------|----------------------|

New regression flag this cycle (P3 — Structured Tool Use):

The v2.1.101 changelog reveals that permissions.deny overriding a hook's permissionDecision: "ask" was only fixed in v2.1.98. This confirms that the harness-enforces-safety principle (the boundary between model reasoning and permission enforcement) had a subtle gap in earlier versions. SI's equivalent — guardrails.py deny-first with no model override path — is structurally correct and arguably ahead of where CC was before v2.1.98. No regression.

One new partial regression flag (not a regression, but a divergence to watch):

The v2.1.94 default effort change to high for Bedrock users means that if SI ever adopts the effort parameter (T027 scope), the default behavior of Bedrock-served Claude models has changed since the baseline. SI's Bedrock calls use "anthropic_beta": ["interleaved-thinking-2025-05-14"] (from prior session reads). If extended thinking is active, the model is already running at a "high effort" equivalent. Adding an explicit effort: high parameter would be redundant and potentially conflict with the beta thinking parameter. T027's golden-sample test suite should include a no-explicit-effort condition as a control.

Regressions this cycle: 0. No code change between 16:30 UTC and 22:30 UTC moved SI away from any CC pattern.

---

4. Top 3 Recommendations This Cycle

These are net-new from all prior cycles. T031, T032, T033 are next unclaimed.

---

Rec M — Audit `titan-bash-guardrail.py` for `permissionDecision: "ask"` Leakage

What. Review titan-bash-guardrail.py to confirm it never returns permissionDecision: "ask" for commands covered by settings.json permissions.deny rules.

Why. CC v2.1.98 fixed a bug where a hook's "ask" decision could downgrade a hard deny to a user prompt. The fix means deny now correctly overrides hook "ask" on CC v2.1.118. However, TITAN is on v2.1.49, where this bug is present. Any TITAN session where titan-bash-guardrail.py returns "ask" on a command that settings.json would deny is silently exposed to the pre-v2.1.98 bug: the user is prompted instead of being hard-denied. After T030 (binary update to v2.1.118), this vulnerability is automatically fixed. Before T030 ships, if titan-bash-guardrail.py ever returns "ask", the deny rule in settings.json does NOT win on the installed v2.1.49 binary.

Scope. Read F:/TITAN/scripts/titan-bash-guardrail.py and check the set of commands where it returns permissionDecision: "ask". Cross-reference against settings.json deny rules. If any command appears in both, document the exposure window. Low blast radius; 0.5-hour audit.

Blast radius: F:/TITAN/scripts/titan-bash-guardrail.py — read-only audit, no changes.

Effort: 0.5 hours (audit) → 15 minutes (patch if exposure found).

Priority: Escalate if bypassPermissions is ever disabled in settings. Under current bypassPermissions mode the deny rules are less critical — but the audit surfaces the gap before the mode is changed.

Source: CC CHANGELOG v2.1.98 (permissions.deny override fix); C:/Users/Harnoor/.claude/settings.json (read 2026-04-23).

---

Rec N — Evaluate Plugin `monitors` for TITAN Real-Time File-Change Awareness

What. Design a titan-monitor plugin that uses the monitors manifest key (v2.1.105+) to stream file-change events from F:/TITAN/knowledge/staging/ and F:/TITAN/plans/ to the Monitor tool during agentic sessions.

Why. TITAN's Stop hook currently fires titan-reflect.py asynchronously after each session ends. This means TITAN has zero real-time awareness of changes to its own knowledge base during a multi-turn session. A monitor would allow the model to observe: "a new staging file was written during the last 3 turns" — enabling spontaneous /dream invocation or escalation to Harnoor without waiting for session end. For audit cycles like this one (which write memos, update registries, and append to logs), a monitor would confirm each write landed before the next step proceeds — a lightweight verification mechanism.

Dependencies. Requires T030 (binary update to v2.1.118) — monitors are v2.1.105+, unavailable on v2.1.49. Estimated implementation: 2 hours for a minimal monitor that watches staging/ and emits filename + timestamp on each new file.

Anti-pattern check. Do not use monitors for user-facing behavior changes. Monitors are TITAN-internal instrumentation only. This is analogous to how CC uses diminishing-returns detection (a pure harness signal) rather than exposing loop-termination logic to the model as a tool.

Blast radius: New file ~/.claude/plugins/titan-monitor/plugin.json + monitor script. Zero Silent Infinity impact. Zero settings.json changes.

Effort: 2 hours (design + script).

Source: CC CHANGELOG v2.1.105 (monitors key); current TITAN settings.json (read 2026-04-23).

---

Rec O — Make `titan-injection-scan.py` Async on Read + Glob + Grep

What. Add "async": true to the titan-injection-scan.py hook entry in settings.json for the Read|WebFetch|WebSearch matcher, or split it to apply only to WebFetch|WebSearch (external untrusted content) and remove it from Read (trusted local files).

Why. The injection scan hook currently runs synchronously (no async: true) on every Read, WebFetch, and WebSearch result. Local file reads (Read tool on ~/.claude/ or F:/TITAN/) are trusted content — they were written by TITAN or Harnoor. Prompt injection via a local file TITAN wrote itself is a non-threat; the threat is external content arriving via WebFetch or WebSearch. Running a synchronous Python injection scan on every Read call adds 50-150ms latency per read operation in the hot path. For a research audit session like this one, the Read tool fires 20+ times, meaning up to 3 seconds of cumulative added latency from a defense that provides no security value on trusted local content.

Proposed split:

Keep titan-injection-scan.py synchronous on WebFetch|WebSearch (external, untrusted).
Remove Read from the injection-scan matcher entirely, or make it async: true if removal feels too aggressive.
This is a 2-line change in settings.json.

Blast radius: C:/Users/Harnoor/.claude/settings.json only. Zero code changes. Zero Silent Infinity impact.

Effort: 5 minutes.

Source: Current settings.json analysis (read 2026-04-23); CC hook behavior documentation.

---

5. Anti-Patterns — CC Features TITAN and SI Should Not Copy

AP-1 (carried forward): bypassPermissions as a long-term mode.

CC's bypassPermissions is designed for trusted automation scenarios. TITAN uses it as the default. This is appropriate for a private, single-user setup where the operator IS the user. It is the correct choice now. It should NOT be adopted by Silent Infinity for any reason — SI serves users who are not the operator.

AP-2 (carried forward): CC verbosity at scale.

CC responses are verbose by default at effort: high. This serves coding tasks where completeness is valued. SI's contemplative mirror should never inherit CC's response density. T027 (golden-sample tests for Opus 4.7) explicitly includes effort-level scoring.

AP-3 (new this cycle): Plugin monitor overreach.

The plugin monitors feature is designed for background awareness, not for making models more agentic during user turns. Monitors that actively modify session context or interrupt the user mid-turn would violate the CC principle: "silent work vs. visible work." A TITAN monitor should observe and record; it should not interrupt Harnoor's active session with unsolicited context injections.

AP-4 (new this cycle): Native binary launcher (v2.1.113) as a CC-specific optimization.

v2.1.113 changed CC's CLI to spawn a native binary instead of bundled JavaScript per-platform. This is a performance optimization for a local CLI tool. SI is a serverless Lambda — binary-level optimizations at the CLI layer are irrelevant. SI's performance is bounded by cold start time, DDB latency, and Bedrock inference speed, none of which are affected by binary launcher architecture.

Source: CC CHANGELOG v2.1.113; prior audit anti-pattern catalog; settings.json (read 2026-04-23).

---

6. TITAN Local Scan — State vs. Baseline

| Artifact | Status vs. Baseline |

|----------|-------------------|

| Skills count (~/.claude/skills/) | 12 confirmed (feed, sense, evolve, pulse, monologue, reflect, newsletter, teach, learn, titan, briefing, dream) — no new skills added |

| Plugin infra (~/.claude/plugins/) | Present — install-counts-cache.json, no plugins installed |

| Telemetry (~/.claude/telemetry/) | 1p_failed_events files present — DISABLE_TELEMETRY not set (T029 OPEN) |

| MCP auth cache (~/.claude/mcp-needs-auth-cache.json) | Present — MCP servers configured (project-scoped) |

| Session transcripts (~/.claude/projects/) | Active — current audit session files |

| autoMemoryDirectory | Configured to F:/TITAN/knowledge/auto-memory/ — requires T030 to verify function on v2.1.118 |

| Hook system | 9 hooks across 6 event types — fully populated (T015 closed) |

| PostCompact hook | Present (titan-postcompact.py) — new since baseline, not in baseline analysis |

New local observation this cycle: The settings.json contains a PreToolUse Bash hook (titan-bash-guardrail.py) that is synchronous with a 5-second timeout. Given TITAN runs in bypassPermissions mode, this hook fires on every Bash call even though permissions are not checked. The hook may be doing validation work that is valuable; the audit does not recommend removing it. But the 5-second timeout on every Bash call is a safety net for a script that ideally runs in <1 second. If titan-bash-guardrail.py is consistently fast, the timeout is fine. If it ever hits 5 seconds (script failure / Python import delay / path not found), every Bash invocation in that session is delayed 5 seconds. The script should include an internal fast-path return (exit 0) for the common case.

---

7. Summary Statistics

| Metric | Count |

|--------|-------|

| New CC release since last audit (1630 UTC) | 0 |

| Confirmed latest CC version | v2.1.118 (April 23, 2026) |

| New patterns analyzed this cycle | 5 (Bash security hardening aggregate, PID sandboxing, plugin monitors, HN community signal, settings.json fresh scan) |

| Silent Infinity regressions | 0 |

| Confirmed existing gaps in SI | 3 (structured tool use P3, skill system P8, session fork endpoint P7) |

| New T-number recommendations | 3 (Rec M → T031, Rec N → T032, Rec O → T033) |

| Anti-patterns added | 2 (AP-3 monitor overreach, AP-4 native binary not applicable to serverless) |

---

8. Sources

1. F:/TITAN/plans/advisors/CLAUDE-CODE-ARCHITECTURE-DEEP-DIVE-2026-04-22.md — baseline (SCOUT, 2026-04-22)

2. F:/TITAN/plans/advisors/claude-code-audit-2026-04-23-1630.md — prior cycle (read 2026-04-23)

3. F:/TITAN/plans/task-registry/TASK-REGISTRY-2026-04-21.md — live task registry (read 2026-04-23)

4. F:/TITAN/plans/audit-cadence.log — audit history (read 2026-04-23)

5. github.com/anthropics/claude-code/releases — release index, confirmed v2.1.118 latest (fetched 2026-04-23)

6. code.claude.com/docs/en/changelog — official CC changelog v2.1.94–v2.1.118 (fetched 2026-04-23)

7. C:/Users/Harnoor/.claude/cache/changelog.md — local CC changelog cache (read 2026-04-23, lines 1–150)

8. C:/Users/Harnoor/.claude/settings.json — TITAN hook + permissions config (read 2026-04-23)

9. C:/Users/Harnoor/.claude/skills/feed/SKILL.md — TITAN /feed skill (read 2026-04-23)

10. C:/Users/Harnoor/.claude/skills/sense/SKILL.md — TITAN /sense skill (read 2026-04-23)

11. C:/Users/Harnoor/.claude/skills/ glob — 12 skills confirmed (globbed 2026-04-23)

12. news.ycombinator.com/item?id=47597085 — Claude Code Unpacked HN thread (~March 2026, fetched 2026-04-23)

13. news.ycombinator.com — HN search results, Claude Code 2026 — Claude Code & Productivity Panic (fetched 2026-04-23)

14. x.com/AnthropicAI — Claude Code security review — official X announcement (fetched 2026-04-23)

15. releasebot.io/updates/anthropic/claude-code — aggregated release notes (fetched 2026-04-23)