Update @github/copilot to 1.0.76-2

[github-actions]

Automated update of @github/copilot to version 1.0.76-2.

Changes

• Updated @github/copilot in nodejs/package.json and test/harness/package.json
• Re-ran all code generators (scripts/codegen)
• Formatted generated output
• Updated Java codegen dependency, POM property, and regenerated Java types

Java Handwritten Code Adaptation Plan

If java-sdk-tests CI fails on this PR, follow these steps:

1. Identify failures: Run mvn clean, mvn verify from java/ locally or check the java-sdk-tests workflow run logs.
2. Categorize errors:
   • Constructor signature changes (new fields added to generated records)
   • Enum value additions/renames in generated types
   • New event types requiring handler registration
   • Removed or renamed generated types
3. Fix handwritten source (java/src/main/java/com/github/copilot/sdk/):
   • Update call sites passing positional constructor args to include new fields (typically null for optional new fields).
   • Update switch/if-else over enum values to handle new cases.
   • Register handlers for new event types in CopilotSession.java if applicable.
4. Fix handwritten tests (java/src/test/java/com/github/copilot/sdk/):
   • Same constructor/enum fixes as above.
   • Add new test methods for new functionality if the change adds user-facing API surface.
5. Validate: cd java && mvn clean test-compile jar:jar && mvn verify -Dskip.test.harness=true
6. Format: cd java && mvn spotless:apply
7. Push fixes to this PR branch.

To automate this, trigger the java-adapt-handwritten-code-to-accept-upgrade-changes agentic workflow instead.

Next steps

When ready, click Ready for review to trigger CI checks.

Created by the Update @github/copilot Dependency workflow.

[github-actions]

Cross-SDK Consistency Review ✅

This PR updates @github/copilot to 1.0.76-2 and introduces a new sqlite_transaction method across all six SDK implementations. The feature is implemented consistently:

SDK	New method	Error type	Exported
Node.js/TypeScript	transaction(statements)	SessionFsSqliteTransactionFailure (class)	✅ index.ts
Python	sqlite_transaction(statements)	SessionFsSqliteTransactionFailure (class)	✅ __init__.py
Go	SqliteTransaction(statements)	SessionFSSqliteTransactionFailure (struct)	✅ exported
.NET	TransactionAsync(statements, ct)	SessionFsSqliteTransactionException (class)	✅ public
Rust	sqlite_transaction(statements)	SessionFsSqliteTransactionError (struct)	✅ types.rs
Java	Generated types updated	Generated SessionFsSqliteTransactionError	✅ generated

No consistency issues found. All SDKs:

• Add the transaction method with the same semantics (execute statements atomically, return one result per statement)
• Provide a way to classify transaction failures (BusyOrLocked / Fatal / PostCommitAmbiguous)
• Handle the "SQLite not supported" case by returning a result-level error (not a transport error)
• Export all new public types
• Include updated E2E tests

The naming differences (.NET uses Exception suffix, Rust uses a return type rather than a thrown exception) appropriately follow each language's conventions.

Generated by SDK Consistency Review Agent for #2118 · sonnet46 71.3 AIC · ⌖ 5.46 AIC · ⊞ 6.6K · ◷

[stephentoub]

CI blocker: --log-level crashes the CLI in @github/copilot 1.0.76-1 and 1.0.76-2

The Java / Node.js / Python required checks are all failing for a single upstream reason, not because of anything in this diff.

Symptom. The CLI exits immediately and silently when started with --log-level set to any of the canonical levels (none, error, warning, info, debug). --log-level all and --log-level default still work, and omitting the flag works.

Root cause. In the bundled app.js, the level-parsing helper reads Lie.Error (etc.) but var Lie = {...} is initialized later on the same top-level line, after the await program.parseAsync(...) that invokes it — a bundler/TLA ordering bug. Running the bundle under a preload hook surfaces:

UNCAUGHT TypeError: Cannot read properties of undefined (reading 'Error')
    at bui (app.js:5723:1466)
    at t.<anonymous> (app.js:5602:823)
    at async t.parseAsync (app.js:78:4208)

Because the crash is an uncaught exception during argument parsing, the process exits with code 0 and no output, which is exactly what CI reports (Error: CLI server exited unexpectedly with code 0, then Error: Connection is closed.). Java sees it as a 30s TimeoutException in CopilotClient.verifyProtocolVersion.

Bisect (copilot --headless --no-auto-update --log-level error --port 0):

Version	Result
1.0.73	✅ listening
1.0.75	✅ listening
1.0.76-0	✅ listening
1.0.76-1	❌ silent exit
1.0.76-2	❌ silent exit

Introduced in 1.0.76-1. Reproduces on Linux, macOS and Windows.

Why only some SDKs fail. It tracks exactly with whether an SDK spawns a real CLI with --log-level:

SDK	Passes --log-level?	CI
Java	always — CopilotClientOptions.logLevel defaults to "info"	❌
Node.js	E2E harness defaults to "error"	❌
Python	E2E passes log_level="error"	❌
Rust	only when with_log_level(...) is called; E2E doesn't	✅ (see below)
.NET	only against a fake CLI / ForUri	✅
Go	never	✅

Note this means the Java SDK is unusable against 1.0.76-2 for every consumer, not just in tests — its default log level is one of the crashing values.

Verified locally: temporarily suppressing the --log-level argument in nodejs/src/client.ts (both the stdio and in-process/FFI spawn paths) turns the Node E2E suites green (44 passed / 2 skipped). That change was reverted and is not part of this branch — dropping a user-requested log level to paper over a dependency bug isn't an acceptable fix.

There is no fixed release to bump to. npm dist-tags for @github/copilot are currently latest: 1.0.75, prerelease: 1.0.76-2.

Separate, smaller issue. rust / Rust SDK Tests (windows-latest, default) fails one test — rpc_shell_edge_cases::shell_exec_with_timeout_kills_long_running_command (387 passed, 1 failed) — timing out waiting for the started marker file. The test execs a powershell command with timeout: Some(200) and expects the child to write a marker before the 200ms kill lands. It fails consistently on this branch and passes on main, which suggests a genuine shell-startup behavior change in 1.0.76-x (plausibly related to the new ShellInitProfile / ShellInitScript / ShellOptions types this PR generates). Leaving it alone rather than loosening the timeout, since that would mask a real behavior change.

Recommendation: hold this PR until a CLI release fixes the --log-level initialization order, then re-run the update workflow against it. I have not filed anything upstream.

Generated by Copilot