Successful apply_patch writes are missing from session file attribution

[doomslayer2k]

Describe the bug

Tooling that asks "which files did this session change?" reports an empty or incomplete fileset after files were successfully modified with apply_patch. The session's file-attribution surface has no row for the written path, so the caller has to fall back to enumerating paths by hand, and any cross-session overlap check silently loses its evidence.

The failure mode is worse than a missing convenience: an empty result is indistinguishable from "this session changed nothing", so an overlap-safety check reads as "no conflict" when the truth is "no data".

Legacy write tools are recorded correctly — attribution rows exist for edit and create. Only apply_patch writes appear to be missing.

Frequency: deterministic in the observed session — every successful apply_patch write was absent. On this machine the local projection contains no apply_patch rows at all.

Extensions: not tested with extensions/plugins disabled. The behaviour is observable through the CLI's own local session-file attribution database and its append-only event log, so it does not look extension-mediated, but I have not confirmed that.

Affected version

Copilot CLI 1.0.80, Windows x64.

Steps to reproduce the behavior

1. Start or resume a CLI session in a repository-backed workspace.
2. Successfully modify a tracked file using apply_patch.
3. Confirm the session's append-only event log contains the matching pair for that call: a tool.execution_start with toolName: apply_patch, and a tool.execution_complete with success: true (correlate on toolCallId).
4. Inspect the CLI's local session-file attribution for that session ID.
5. Observe there is no row for the path that was just written.
6. Contrast with older sessions: rows are present there, but their tool name is only ever edit or create.

Expected behavior

Every tool that successfully writes a file should be represented in the supported session file-attribution surface — at minimum session ID, canonical path, tool name, and last-write time. Patches that fail or are denied must not produce a row.

If session_files is not intended as a supported contract for consumers, then please expose a supported API or event that provides complete write attribution, so callers have a documented way to answer "what did this session touch?" without scraping the raw event log.

Additional context

Desired labels for triage (I can't set labels as an outside contributor): area:tools, area:sessions.

Impact / workaround: I've added a local sidecar that records successful writes after the tool completes, which restores the answer going forward. It cannot repair the engine's own projection, and it only covers sessions where the sidecar is installed — so historical and cross-machine data stays lossy.

Possibly related, but not the same issue:

• "No files in workspace yet." when /session files #1416 — /session files shows "No files in workspace yet."; that report is about files in the session-state folder, not apply_patch writes to workspace files.
• session_store_sql silently returns empty when session sync is set to local #2654 — session_store_sql returns empty under local-only sync; a different (routing) cause for an empty answer.

In-depth investigation

Measurements below are from a single machine's local session store; I'm reporting them as one-machine evidence rather than a claim about every install.

Current session, cross-checked against its own event log:

• The session's event log contained successful apply_patch calls — tool.execution_start (toolName: apply_patch) paired by toolCallId with tool.execution_complete (success: true).
• The same session's file-attribution row count was zero.

So the write is present in the event log and absent from the projection derived from it, which points at the projection/attribution step rather than at tool execution or at the log itself.

Across the whole local projection:

Measure	Value
Recent attribution rows	2,274
Distinct tool_name values	edit, create only
Rows with tool_name = apply_patch	0
Newest row	Aug 27

The newest row predates several later sessions that definitely performed patch-based edits — consistent with attribution having stopped being written once apply_patch became the effective write path, rather than with those sessions doing no work.

Shape of a likely fix: whatever hook records edit/create completions into attribution appears to enumerate write tools by name, and apply_patch was never added to it. Recording on successful completion (and extracting the target path from the patch) would cover it; gating on success: true keeps failed and denied patches out.