Claude Code just tightened its sandbox—while VS Code hooks are quietly ignoring the boundary you set. Quick catch-up: coding-agent harness security has been moving on several fronts. Novee Security flagged risks in default harnesses, and Claude Code has shipped hardening releases. Separately, a Hermes Agent issue showed backend provider error envelopes reaching model context verbatim. Before today, the latest Claude Code release was v2.1.247, which added SendFeedback and fixed sub-agent fallback and oversized provider-error output that could wedge a session. This is AI Coding Daily. Today, a production sandbox control—and a VS Code hook that fires when it shouldn't. Plus a CI gate that catches a passing PR with missing authorization. Here's Anthropic:
What's changed Added --restricted (or CLAUDE_CODE_RESTRICTED=1 ): removes the built-in tools that run commands or code and WebFetch (unless named in --tools ), keeps file tools inside the working directory, refuses bypassPermissions, and ignores user, project and local settings files Added experimental.cacheTtl ( "5m" or "1h" ) to agent frontmatter: a per-agent prompt cache TTL used when no subagent TTL setting is configured
Claude Code v2.1.248 adds restricted mode for agent runs. --restricted strips command execution, code-running tools, and WebFetch unless you explicitly add them back through --tools. It also refuses bypassPermissions outright and ignores user, project, and local settings. For a long-running agent, the operator gets the final say—not some frontmatter file committed six months ago. That changes the deployment posture in a real way. File tools stay inside the working directory, so a review-only or repository-inspection job has far less blast radius. Simon Willison’s prompt-injection research makes removing those execution tools especially relevant. Teams do need to inventory their agent configs before flipping it on. If an existing workflow depended on settings files or bypassPermissions, it may fail loudly—which is far preferable to discovering it quietly gave itself a shell. There’s also experimental.cacheTtl in agent frontmatter: five minutes or one hour, used when no subagent TTL is set. Per-agent cache policy is a useful step toward attributing long-run cost, though it still doesn’t tell you which model consumed the tokens. This one's from GitHub:
Observe that the hook fires for every tool call, not just Read. Expected Behavior: The hook should only fire when the tool name matches the matcher value (e.g. "Read"). This is how Copilot CLI behaves. hooks with matchers are filtered at execution time so they only run for matching tools. Actual Behavior: The matcher field is silently discarded during parsing. All PostToolUse hooks fire for every tool call regardless of matcher.
A matcher set to "Read" that fires after every tool call is a serious parsing bug. In VS Code 1.135.0, any shop using PostToolUse hooks for tool-scoped controls has had its boundary widened without being told. Issue #332988 says the field is silently discarded, while Copilot CLI filters it at execution time. That matters: a hook that spawns a command after every edit, search, or read changes both the security surface and the latency budget of an agent session. And it’s open, assigned to pwang347, with a related report saying it spawns a process on every tool call in every session. Congratulations: your narrowly scoped guardrail is now a very enthusiastic background chore. We just covered Claude Code shipping --restricted, an operator control that reduces available tools. Here, the configuration says one thing and the IDE does another. Teams relying on hooks should test a deliberately non-matching tool call before treating that policy as enforced. Here's OpenAI:
The Codex/ChatGPT Windows Desktop app does not display any window after launch. When I launch it from the Start menu, desktop shortcut, shell:AppsFolder, or directly from ChatGPT.exe, multiple ChatGPT.exe background processes appear in Task Manager, but: - No desktop window appears. - No taskbar item appears. - No ChatGPT/Codex entry appears in Alt+Tab. - There is no visible error dialog.
Five to seven ChatGPT.exe processes on Windows x64, no window, no taskbar entry, no Alt+Tab, no Event Viewer error. It’s consuming resources while giving the operator absolutely nothing to debug. The report on Codex App 26.820.9563.0 gets specific: Chromium’s GPU, network, storage, and Crashpad children launch, but the main UI never materializes. And the declared Codex user-data directory isn’t created, despite being writable. Closed in seven minutes is fast triage, not a repair note. For a Windows desktop client, “the process exists” is a pretty miserable definition of launched. Especially after that VS Code hooks regression, here’s another case where visible configuration and runtime behavior part ways. The app’s process tree says it’s alive; at the keyboard, you get a blank desktop. Here's Claude Code at GitHub:
A mapping-only payload through validate_python measures +0, which isolates the residual to sequence nodes: pydantic's own sequence_validator costs a Python frame per sequence node in python mode. validate_json stays entirely in Rust. So the one adapter path that already has a JSON string takes the python entry point
A 200-row tool return adds 1,188 Python calls because AG-UI parses JSON, then walks it in Python anyway. That’s the kind of tax nobody sees until the agent starts moving real-sized payloads. The proposed change needs care: json.loads preserves the distinction between the string '123' and the number 123. So it can’t be a blind validate_json substitution; it needs the 1 KB, 37 KB, and 1 MB timing sweep the issue proposes. And it was Claude Code, running claude-opus-5, that filed #7826 for David. Good catch—just benchmark the double-parse before turning a Rust fast path into a small-payload slowdown. From Momcilo Savic at DEV Community:
AI coding agents are good at producing a diff that works in the narrowest sense — the function still returns what the test expects. What they're not reliably good at is preserving properties nobody wrote a test for in the first place. The two we kept running into: an authorization check quietly dropped during an agent-driven refactor
This DEV post puts a name to the PR failure I actually worry about: the route still works, the test stays green, and the authorization check vanished somewhere inside a 300-line agent refactor. HumanEval isn’t visiting that codepath. Their Agent Code Merge Gate stays deliberately narrow: dropped auth checks and queries that turn into full-table scans at production scale. It runs an offline diff pass, then produces an AI summary and one updating PR comment instead of notification confetti. Set fail-on-critical: true and the finding blocks the merge. Good. A comment asking people to notice a missing permission check is how you end up explaining an incident to compliance. Pair that with the VS Code matcher regression we just covered: CI can catch a dangerous diff, but local PostToolUse hooks firing for every tool means the orchestration boundary is already lying to the developer. You need both layers to work. If you’re enjoying AI Coding Daily, please subscribe and leave us a review wherever you’re listening. Reviews help other people find the show, and they help us keep bringing you the latest in AI coding.
Links to every story we covered are in the show notes, so take a closer look at anything that caught your attention. That’s AI Coding Daily for Friday. This is a Lantern Podcast.