dotnet sdk copilot session hangs after postToolUseFailure

[akashlal]

I am using dotnet sdk version 0.2.1. I started noticing that a lot of copilot sessions started to hang. On debugging the session logs, I found the following repeated pattern. After a postToolUseFailure, the session just shutdown. To my client, it just appears that the session has hung. My environment is Windows, dotnet SDK 10.0.201. Below are the relevant logs from multiple independent sessions. You can see that the tool failures are mostly benign (file does not exist) and I would expect copilot to recover from it. Timestamps indicate that the session shutdown immediately after the postToolUseFailure.

# Session 1

```json
{"type":"hook.start","data":{"hookInvocationId":"50cd61a0-54a4-47b3-ba9e-f72950a76a2d","hookType":"postToolUseFailure","input":{"sessionId":"0ab2ff80-9dce-426e-9f56-ebf240ff1256","timestamp":1775351382397,"cwd":"C:\\Users\\akashl\\work\\decoder\\workspace","toolName":"view","toolArgs":{"path":"C:\\Users\\akashl\\work\\decoder\\workspace\\board\\issues-board.yaml"},"error":"Path does not exist"}},"id":"8cd5ea7e-8631-4e7a-bbd9-addd856ca93a","timestamp":"2026-04-05T01:09:42.397Z","parentId":"4d9408db-8422-4f2e-a448-710e8dfda472"}
{"type":"session.shutdown","data":{"shutdownType":"routine","totalPremiumRequests":1,"totalApiDurationMs":6827,"sessionStartTime":1775351373741,"codeChanges":{"linesAdded":0,"linesRemoved":0,"filesModified":[]},"modelMetrics":{"gpt-5.4":{"requests":{"count":1,"cost":1},"usage":{"inputTokens":14919,"outputTokens":390,"cacheReadTokens":1536,"cacheWriteTokens":0}}},"currentModel":"gpt-5.4","currentTokens":16725,"systemTokens":8154,"conversationTokens":3471,"toolDefinitionsTokens":5097},"id":"a4d251a0-455a-4364-8e2c-227163dee8cd","timestamp":"2026-04-05T01:09:42.709Z","parentId":"8cd5ea7e-8631-4e7a-bbd9-addd856ca93a"}
```

# Session 2

```json
{"type":"hook.start","data":{"hookInvocationId":"e089362f-5067-4061-aade-50845f62a166","hookType":"postToolUseFailure","input":{"sessionId":"59a5cec1-8a0c-4c75-bace-41b09fe0de22","timestamp":1775371575365,"cwd":"C:\\Users\\akashl\\work\\decoder\\workspace","toolName":"view","toolArgs":{"path":"C:\\Users\\akashl\\work\\decoder\\workspace\\board\\issues-board.yaml"},"error":"Path does not exist"}},"id":"169609bf-fdab-42fd-ba18-bc737fe2a0b3","timestamp":"2026-04-05T06:46:15.365Z","parentId":"a41548c3-a18c-4132-989e-d9bf1e41a668"}
{"type":"session.shutdown","data":{"shutdownType":"routine","totalPremiumRequests":1,"totalApiDurationMs":7250,"sessionStartTime":1775371567784,"codeChanges":{"linesAdded":0,"linesRemoved":0,"filesModified":[]},"modelMetrics":{"gpt-5.4":{"requests":{"count":1,"cost":1},"usage":{"inputTokens":14925,"outputTokens":509,"cacheReadTokens":10752,"cacheWriteTokens":0}}},"currentModel":"gpt-5.4","currentTokens":16048,"systemTokens":8160,"conversationTokens":2788,"toolDefinitionsTokens":5097},"id":"b4971317-fffe-43f4-aee0-c5884f781d0b","timestamp":"2026-04-05T06:46:15.776Z","parentId":"169609bf-fdab-42fd-ba18-bc737fe2a0b3"}
```

# Session 3

```json
{"type":"hook.start","data":{"hookInvocationId":"6e83d1c9-6c9d-4e61-950d-4ed693367f96","hookType":"postToolUseFailure","input":{"sessionId":"6173f773-31f1-466d-9f66-1d344f61961f","timestamp":1775216744300,"cwd":"C:\\Users\\akashl\\work\\decoder\\workspace","toolName":"create","toolArgs":{"path":"C:\\Users\\akashl\\work\\decoder\\workspace\\inventory\\decomposition-check.json","file_text":"{ \"complete\": true }"},"error":"Path already exists"}},"id":"704adde3-21c8-48f0-9470-b8b68ec5c11f","timestamp":"2026-04-03T11:45:44.300Z","parentId":"cf15358a-db88-4dac-8909-78acad665780"}
{"type":"session.shutdown","data":{"shutdownType":"routine","totalPremiumRequests":3,"totalApiDurationMs":555951,"sessionStartTime":1775216330206,"codeChanges":{"linesAdded":0,"linesRemoved":0,"filesModified":[]},"modelMetrics":{"claude-opus-4.6":{"requests":{"count":18,"cost":3},"usage":{"inputTokens":770405,"outputTokens":16944,"cacheReadTokens":680167,"cacheWriteTokens":0}},"claude-haiku-4.5":{"requests":{"count":28,"cost":0},"usage":{"inputTokens":781865,"outputTokens":30273,"cacheReadTokens":592720,"cacheWriteTokens":0}}},"currentModel":"claude-opus-4.6","currentTokens":70935,"systemTokens":7857,"conversationTokens":56766,"toolDefinitionsTokens":6308},"id":"e513e39f-a2bd-45fa-8508-1d9682680047","timestamp":"2026-04-03T11:45:44.757Z","parentId":"704adde3-21c8-48f0-9470-b8b68ec5c11f"}
```

# Session 4

```json
{"type":"hook.start","data":{"hookInvocationId":"3d929cd6-178b-4f9c-84d4-1f78470281e0","hookType":"postToolUseFailure","input":{"sessionId":"206089e3-aac9-4bc9-a7fa-234fce45700c","timestamp":1775368618281,"cwd":"C:\\Users\\akashl\\work\\decoder\\workspace","toolName":"glob","toolArgs":{"pattern":"**/*","path":"C:\\Users\\akashl\\work\\decoder\\dav1d-rs"},"error":"timeout"}},"id":"5ff3c32d-bf8c-414e-a4e4-45407fbfc12b","timestamp":"2026-04-05T05:56:58.281Z","parentId":"adc5e7eb-b4fe-43a0-937d-7caa37b7c999"}
{"type":"session.shutdown","data":{"shutdownType":"routine","totalPremiumRequests":1,"totalApiDurationMs":9563,"sessionStartTime":1775368588368,"codeChanges":{"linesAdded":0,"linesRemoved":0,"filesModified":[]},"modelMetrics":{"gpt-5.4":{"requests":{"count":1,"cost":1},"usage":{"inputTokens":14916,"outputTokens":639,"cacheReadTokens":10752,"cacheWriteTokens":0}}},"currentModel":"gpt-5.4","currentTokens":30836,"systemTokens":8151,"conversationTokens":17585,"toolDefinitionsTokens":5097},"id":"a02d3240-af74-4794-923b-1fc88eb89866","timestamp":"2026-04-05T05:56:58.690Z","parentId":"5ff3c32d-bf8c-414e-a4e4-45407fbfc12b"}
```

[github-actions]

Bug Confirmed ✅

I've investigated the source code and confirmed this is a genuine bug in the .NET SDK.

Root Cause

The Copilot CLI emits hook.start events with hookType: "postToolUseFailure" when a tool use fails. This is a valid hook type not handled by any SDK right now, but only the .NET SDK crashes when it receives it.

In dotnet/src/Session.cs, the HandleHooksInvokeAsync method uses a switch expression that throws an ArgumentException for any unrecognized hook type:

return hookType switch
{
    "preToolUse" => ...
    "postToolUse" => ...
    "userPromptSubmitted" => ...
    "sessionStart" => ...
    "sessionEnd" => ...
    "errorOccurred" => ...
    _ => throw new ArgumentException($"Unknown hook type: {hookType}")  // ← throws for "postToolUseFailure"
};

This exception propagates as an RPC error back to the Copilot CLI. The CLI interprets this hook handler failure as a reason to perform a routine session shutdown — explaining the pattern you see in all four of your log samples: hook.start (postToolUseFailure) immediately followed by session.shutdown (routine), within ~300ms.

Why it looks like a "hang"

From your client's perspective, the SendMessageAsync call never resolves — because the session has been shut down underneath it without your code receiving a clean completion event.

Comparison with other SDKs

The Node.js and Python SDKs use dictionary lookup (not a switch), so they gracefully return undefined/None for unknown hook types and the session continues uninterrupted. The Go SDK has the same underlying defect (returns an error for unknown hook types via its default switch case).

Fix needed

The minimum fix for the .NET SDK is to change the default switch arm from throwing to returning null:

_ => null   // gracefully ignore unrecognized hook types

Ideally, postToolUseFailure should be added as a first-class hook type with a corresponding OnPostToolUseFailure handler in SessionHooks, matching the CLI's full hook vocabulary.

The Go SDK's default: return nil, fmt.Errorf("unknown hook type: %s", hookType) should be similarly fixed (return nil, nil).

Generated by Bug Handler for issue #1005 · ◷