feat: add hooks and user input handlers to all SDKs with e2e tests

[friggeri]

• Add preToolUse, postToolUse, and other hook callbacks to Node.js, Python, Go, .NET SDKs
• Add requestUserInput callback (ask_user) to all SDKs
• Fix .NET SDK bug: StreamJsonRpc requires explicit = null defaults for optional parameters
• Add e2e tests for hooks (4 tests) and ask-user (3 tests) in all SDKs
• Create shared test snapshots for consistent LLM responses across SDKs

[Copilot]

Pull request overview

This pull request adds comprehensive hooks and user input handling capabilities across all Copilot SDKs (Python, Node.js, Go, and .NET), enabling developers to intercept and customize session lifecycle events and implement interactive user input flows via the ask_user tool.

Changes:

• Adds six hook types (preToolUse, postToolUse, userPromptSubmitted, sessionStart, sessionEnd, errorOccurred) to all SDKs
• Adds user input handler (ask_user tool) support to all SDKs
• Includes comprehensive e2e tests (4 hooks tests + 3 ask_user tests) for each SDK
• Creates shared test snapshots for consistent LLM response mocking
• Updates @github/copilot dependency from 0.0.394 to 0.0.399
• Fixes .NET StreamJsonRpc bug requiring explicit = null defaults for optional parameters
• Adds workingDirectory and disableResume configuration options

Reviewed changes

Copilot reviewed 41 out of 43 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
python/copilot/{types,session,client}.py	Adds hook handler types, user input types, and handler registration/invocation logic
nodejs/src/{types,session,client}.ts	Adds TypeScript interfaces for hooks and user input with handler registration
go/{types,session,client}.go	Adds Go structs and handlers for hooks and user input functionality
dotnet/src/{Types,Session,Client}.cs	Adds C# types with StreamJsonRpc-compatible optional parameters
python/e2e/test_{hooks,ask_user}.py	Python e2e tests verifying hook invocations and user input flows
nodejs/test/e2e/{hooks,ask-user}.test.ts	Node.js e2e tests with Vitest assertions
go/e2e/{hooks,ask_user}_test.go	Go e2e tests using standard testing package
dotnet/test/{Hooks,AskUser}Tests.cs	.NET xUnit tests for hooks and user input
test/snapshots/{hooks,askuser,ask_user,ask-user}/*.yaml	Shared test snapshots with LLM responses (has duplicate/inconsistent files)
{nodejs,test/harness}/package*.json	Dependency updates to copilot 0.0.399
.vscode/settings.json	Adds Ruff as Python formatter

Files not reviewed (2)

• nodejs/package-lock.json: Language not supported
• test/harness/package-lock.json: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

✅ Cross-SDK Consistency Review: PASSED

I've reviewed this PR for consistency across all four SDK implementations (Node.js/TypeScript, Python, Go, and .NET), and I'm pleased to report that the changes demonstrate excellent cross-SDK consistency.

Summary of Changes

This PR adds two major features to all SDKs:

1. Session Hooks: Pre/post tool use, user prompt submitted, session start/end, and error occurred hooks
2. User Input Handler: ask_user tool support for agent-to-user communication

Consistency Findings ✅

1. API Naming Conventions - Consistent

All SDKs follow their respective language conventions properly:

Feature	Node.js	Python	Go	.NET
Hooks Config	onPreToolUse	on_pre_tool_use	OnPreToolUse	OnPreToolUse
User Input	onUserInputRequest	on_user_input_request	OnUserInputRequest	OnUserInputRequest
Hook Types	PreToolUseHookInput	PreToolUseHookInput	PreToolUseHookInput	PreToolUseHookInput

2. Type Definitions - Consistent

All SDKs define the same hook types with equivalent fields:

• ✅ PreToolUseHookInput/Output with permissionDecision, modifiedArgs, additionalContext, suppressOutput
• ✅ PostToolUseHookInput/Output with modifiedResult, additionalContext, suppressOutput
• ✅ UserPromptSubmittedHookInput/Output
• ✅ SessionStartHookInput/Output
• ✅ SessionEndHookInput/Output
• ✅ ErrorOccurredHookInput/Output
• ✅ UserInputRequest/Response with question, choices, allowFreeform, answer, wasFreeform

3. Session Configuration - Consistent

All SDKs expose hooks and user input handlers through SessionConfig:

• Node.js: SessionConfig.hooks, SessionConfig.onUserInputRequest
• Python: SessionConfig["hooks"], SessionConfig["on_user_input_request"]
• Go: SessionConfig.Hooks, SessionConfig.OnUserInputRequest
• .NET: SessionConfig.Hooks, SessionConfig.OnUserInputRequest

4. E2E Test Coverage - Consistent

All four SDKs include identical test scenarios:

Hooks Tests (4 tests each):

1. Should invoke preToolUse hook when model runs a tool
2. Should invoke postToolUse hook after model runs a tool
3. Should invoke both hooks for a single tool call
4. Should deny tool execution when preToolUse returns deny

Ask User Tests (3 tests each):

1. Should invoke user input handler when model uses ask_user tool
2. Should receive choices in user input request
3. Should handle freeform user input response

5. Implementation Architecture - Consistent

All SDKs follow the same architectural pattern:

• ✅ Handlers registered in createSession/resumeSession
• ✅ Internal registration methods: registerHooks(), registerUserInputHandler()
• ✅ Thread-safe handler storage with mutexes/locks
• ✅ Proper RPC integration for hook invocations
• ✅ Consistent error handling (no handler = error thrown)

6. Documentation - Consistent

All SDKs include proper JSDoc/docstring comments with:

• ✅ Purpose of each hook type
• ✅ Parameter descriptions
• ✅ Return value documentation
• ✅ Internal method markers

Minor Observations (Not Issues)

1. Optional Return Values: All SDKs correctly handle hooks that can return null/undefined/None for no-op cases
2. Async Support: All SDKs properly support both sync and async handler functions
3. .NET StreamJsonRpc Quirk: The PR description mentions fixing a .NET bug requiring explicit = null defaults for optional parameters - this is language-specific and doesn't affect cross-SDK consistency

Conclusion

This PR maintains 100% feature parity across all four SDKs. The naming follows language conventions, types are equivalent, tests are comprehensive and parallel, and the implementation architecture is consistent. This is a model example of how multi-language SDK features should be implemented.

No action items or changes needed. 🎉

---

Reviewed by SDK Consistency Review Agent

AI generated by SDK Consistency Review Agent