{"version":"2.1.265","anchor":"tool-execution-context-exposes-new-capabilities-file-histor","canonical_anchor":"tool-execution-context-exposes-new-capabilities-file-histor","heading":"Tool execution context exposes new capabilities: file history, dedup, isolation latch","tier":"internal","area":"Tooling Architecture","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/tool-execution-context-exposes-new-capabilities-file-histor","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Tool execution context exposes new capabilities: file history, dedup, isolation latch\n\nTool execution context gains new internal capabilities for file history, read deduplication, and isolation\n\n**Unclear.** What most of these new fields (agentWorktree, isolationLatch, turnMcpClients, etc.) actually enable for tools is not shown by the evidence.\n\n**What**\n\nThe internal context object passed to tool calls (the data each tool gets access to when it runs) gained a batch of new capabilities, including:\n\n- `agentWorktree`, `readFileState`, `getFileHistoryState`, and `applyFileHistoryOp`, for tracking and modifying file history\n\n- `dynamicSkillDirTriggers` and `nestedMemoryAttachmentTriggers`, related to skills and memory attachment\n\n- `dedupUnchangedReads`, `setArtifactReadVersion`, and `getArtifactReadObservation`, related to deduplicating unchanged file reads\n\n- `turnMcpClients` and `isolationLatch`\n\n**Why**\n\nThis is internal plumbing that expands what tools can access during execution. The evidence doesn't describe a user-visible behavior change beyond what's already documented for `dedupUnchangedReads` (which lets an individual read opt out of the existing suppression of re-reads of unchanged files).\n\n- Area: Tooling Architecture\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}