Skip to content

Add shared Windows.UI.Shell.Tasks integration to SDK crate - #2257

Open
DevGhub007 wants to merge 1 commit into
mainfrom
dechauh-shell-tasks-sdk
Open

Add shared Windows.UI.Shell.Tasks integration to SDK crate#2257
DevGhub007 wants to merge 1 commit into
mainfrom
dechauh-shell-tasks-sdk

Conversation

@DevGhub007

Copy link
Copy Markdown

Factor the common Rust integration with the experimental Windows.UI.Shell.Tasks ("Forerunner" / taskbar presence) API, previously duplicated between the Copilot desktop app (github/github-app) and the CLI (github/copilot-agent-runtime), into the github-copilot-sdk crate so both products can consume one implementation.

New shell_tasks module under rust/src/shell_tasks/, behind the off-by-default shell-tasks Cargo feature:

  • contract: verbatim copy of the CLI taskbar-contract crate. Pure-std, FFI-free contract for the hover-card round-trip (named-pipe name, focus sidecar file name, sidecar payload format) with its unit tests.
  • bindings: verbatim copy of the CLI vendored WinRT projection of AppTaskContract, re-exported as Windows. Gated on #[cfg(windows)].

The windows/windows-core deps are optional and Windows-only (declared under [target.'cfg(windows)'.dependencies]), activated only by the shell-tasks feature, mirroring how bundled-cli gates its optional zip dep. Non-Windows and feature-off builds pull neither crate.

Verified on Windows: default cargo check plus cargo build/test/clippy/doc --features shell-tasks all green (contract unit tests pass).

Add shared AppTaskContent builder to shell_tasks module

Extract the WinRT AppTaskContent call sequence that the Copilot desktop app and CLI implement identically into a neutral, data-driven builder.

The new content module exposes a cross-platform ContentSpec/ContentBody data model plus #[cfg(windows)] build_content/make_uri/make_result_asset helpers that faithfully reproduce both products' WinRT sequences (CreateSequenceOfSteps, CreatePreviewThumbnail, CreateTextSummaryResult, CreateGeneratedAssetsResult, SetQuestion, AddButton, SetTextInput, AppTaskResultAsset::CreateInstance). Product-specific preparation (template dispatch, asset caps, file:// resolution, deep-link building) stays in each adapter, which hands the builder an already-resolved spec.

Feature-gated behind shell-tasks; 4 new unit tests (15 total).

Add shared sparse-package identity registrar to shell_tasks

Factor the WinRT sparse (external-location) package registration routine out of the CLI's napi bridge into a napi-free shell_tasks::sparse module so both the CLI and the desktop app can share one implementation.

The module exposes plain synchronous, #[cfg(windows)] functions (register_sparse_package, deregister_sparse_package, current_package_family_name) plus the process-lifetime MTA keepalive (ensure_process_mta) that guards windows-rs's cached activation factories against the 0xC0000005 fault. Neutral result types (RegisterOutcome, SparseError) compile on every platform. Each product wraps these in its own async surface (CLI napi AsyncTask; app spawn_blocking/Tauri) and keeps its own AppxManifest and registration trigger.

Adds ApplicationModel/Management_Deployment/Win32_System_Com to the Windows-only optional windows dep. Feature-gated behind shell-tasks; 2 new cross-platform tests (19 total).

Extract shell_tasks into standalone github-copilot-shell-tasks crate

Move the shared Windows.UI.Shell.Tasks integration out of the github-copilot-sdk client crate into a standalone, build.rs-free workspace member at rust/crates/github-copilot-shell-tasks so it can be consumed by the CLI's napi addon (and the desktop app's Tauri backend) without dragging in the full SDK client dependency tree or its network-touching build.rs.

  • New crate github-copilot-shell-tasks (lib github_copilot_shell_tasks) owns contract/content/sparse/bindings; only deps are the Windows-only windows/windows-core crates, gated under cfg(windows).
  • rust/Cargo.toml becomes the workspace root; the shell-tasks feature now pulls the optional path dep, and the client re-exports it as github_copilot_sdk::shell_tasks. windows/windows-core deps moved to the new crate.

Validated on Windows: standalone crate builds with no download and no warnings; 17 tests pass; clippy/doc clean; client builds/docs with --features shell-tasks; default (feature-off) check unaffected.

Re-export windows/windows-core from shell-tasks crate for island consumers

Add pub use ::windows; and pub use ::windows_core; (both #[cfg(windows)]) to the github-copilot-shell-tasks crate root so a consumer that adopts the crate as an isolated WinRT island (the desktop app's Tauri backend, pinned to an older windows via Tauri/wry) can funnel all of its Windows.UI.Shell.Tasks call-sites and the supporting WinRT types (Foundation::Uri, ApplicationModel::Package, Win32::System::Com, HSTRING) through the exact windows 0.62 version the projection was generated against, without declaring its own conflicting windows dependency.

Crate build, clippy, and 17 unit tests pass; the client crate still builds with the shell-tasks feature.

Factor the common Rust integration with the experimental
Windows.UI.Shell.Tasks ("Forerunner" / taskbar presence) API, previously
duplicated between the Copilot desktop app (github/github-app) and the CLI
(github/copilot-agent-runtime), into the github-copilot-sdk crate so both
products can consume one implementation.
New `shell_tasks` module under `rust/src/shell_tasks/`, behind the
off-by-default `shell-tasks` Cargo feature:
- `contract`: verbatim copy of the CLI `taskbar-contract` crate. Pure-std,
FFI-free contract for the hover-card round-trip (named-pipe name, focus
sidecar file name, sidecar payload format) with its unit tests.
- `bindings`: verbatim copy of the CLI vendored WinRT projection of
AppTaskContract, re-exported as `Windows`. Gated on `#[cfg(windows)]`.
The `windows`/`windows-core` deps are optional and Windows-only (declared
under [target.'cfg(windows)'.dependencies]), activated only by the
`shell-tasks` feature, mirroring how `bundled-cli` gates its optional `zip`
dep. Non-Windows and feature-off builds pull neither crate.
Verified on Windows: default `cargo check` plus `cargo
build/test/clippy/doc --features shell-tasks` all green (contract unit
tests pass).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 67c6593a-bb90-4106-a143-49c19fa32a0d
Add shared AppTaskContent builder to shell_tasks module
Extract the WinRT AppTaskContent call sequence that the Copilot desktop
app and CLI implement identically into a neutral, data-driven builder.
The new content module exposes a cross-platform ContentSpec/ContentBody
data model plus #[cfg(windows)] build_content/make_uri/make_result_asset
helpers that faithfully reproduce both products' WinRT sequences
(CreateSequenceOfSteps, CreatePreviewThumbnail, CreateTextSummaryResult,
CreateGeneratedAssetsResult, SetQuestion, AddButton, SetTextInput,
AppTaskResultAsset::CreateInstance). Product-specific preparation
(template dispatch, asset caps, file:// resolution, deep-link building)
stays in each adapter, which hands the builder an already-resolved spec.
Feature-gated behind shell-tasks; 4 new unit tests (15 total).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 67c6593a-bb90-4106-a143-49c19fa32a0d
Add shared sparse-package identity registrar to shell_tasks
Factor the WinRT sparse (external-location) package registration routine
out of the CLI's napi bridge into a napi-free shell_tasks::sparse module
so both the CLI and the desktop app can share one implementation.
The module exposes plain synchronous, #[cfg(windows)] functions
(register_sparse_package, deregister_sparse_package,
current_package_family_name) plus the process-lifetime MTA keepalive
(ensure_process_mta) that guards windows-rs's cached activation
factories against the 0xC0000005 fault. Neutral result types
(RegisterOutcome, SparseError) compile on every platform. Each product
wraps these in its own async surface (CLI napi AsyncTask; app
spawn_blocking/Tauri) and keeps its own AppxManifest and registration
trigger.
Adds ApplicationModel/Management_Deployment/Win32_System_Com to the
Windows-only optional windows dep. Feature-gated behind shell-tasks;
2 new cross-platform tests (19 total).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 67c6593a-bb90-4106-a143-49c19fa32a0d
Extract shell_tasks into standalone github-copilot-shell-tasks crate
Move the shared Windows.UI.Shell.Tasks integration out of the
github-copilot-sdk client crate into a standalone, build.rs-free
workspace member at rust/crates/github-copilot-shell-tasks so it can be
consumed by the CLI's napi addon (and the desktop app's Tauri backend)
without dragging in the full SDK client dependency tree or its
network-touching build.rs.
- New crate github-copilot-shell-tasks (lib github_copilot_shell_tasks)
owns contract/content/sparse/bindings; only deps are the Windows-only
windows/windows-core crates, gated under cfg(windows).
- rust/Cargo.toml becomes the workspace root; the shell-tasks feature now
pulls the optional path dep, and the client re-exports it as
github_copilot_sdk::shell_tasks. windows/windows-core deps moved to the
new crate.
Validated on Windows: standalone crate builds with no download and no
warnings; 17 tests pass; clippy/doc clean; client builds/docs with
--features shell-tasks; default (feature-off) check unaffected.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 67c6593a-bb90-4106-a143-49c19fa32a0d
Re-export windows/windows-core from shell-tasks crate for island consumers
Add `pub use ::windows;` and `pub use ::windows_core;` (both `#[cfg(windows)]`)
to the `github-copilot-shell-tasks` crate root so a consumer that adopts the
crate as an isolated WinRT island (the desktop app's Tauri backend, pinned to
an older `windows` via Tauri/wry) can funnel all of its Windows.UI.Shell.Tasks
call-sites and the supporting WinRT types (Foundation::Uri,
ApplicationModel::Package, Win32::System::Com, HSTRING) through the exact
`windows` 0.62 version the projection was generated against, without declaring
its own conflicting `windows` dependency.
Crate build, clippy, and 17 unit tests pass; the client crate still builds with
the `shell-tasks` feature.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 67c6593a-bb90-4106-a143-49c19fa32a0d
CopilotAI balanced review requested due to automatic review settings August 4, 2026 19:01

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Introduces a standalone, feature-gated Rust crate for shared Windows taskbar-presence integration.

Changes:

  • Adds shared contracts, content builders, sparse-package registration, and WinRT bindings.
  • Re-exports the crate through the Rust SDK.
  • Adds workspace configuration and Windows dependencies.
Show a summary per file
FileDescription
rust/src/lib.rsRe-exports the shell-tasks crate.
rust/crates/github-copilot-shell-tasks/src/lib.rsDefines the crate’s public API.
rust/crates/github-copilot-shell-tasks/src/contract.rsImplements cross-process sidecar contracts.
rust/crates/github-copilot-shell-tasks/src/content.rsAdds neutral content specifications and WinRT builders.
rust/crates/github-copilot-shell-tasks/src/sparse.rsAdds sparse-package and COM helpers.
rust/crates/github-copilot-shell-tasks/src/bindings.rsVendors generated WinRT projections.
rust/crates/github-copilot-shell-tasks/Cargo.tomlConfigures the standalone crate.
rust/Cargo.tomlAdds workspace membership, dependency, and feature.
rust/Cargo.lockLocks the new Windows dependency graph.

Review details

Suppressed comments (1)

rust/crates/github-copilot-shell-tasks/src/sparse.rs:137

  • CoInitializeEx can fail, but the closure still invokes WinRT as though COM initialization succeeded. On this freshly spawned thread, a failed HRESULT means the required MTA was not established, so subsequent deployment calls can fail unpredictably and obscure the real cause. Return the initialization error before calling f.
 let hr = CoInitializeEx(None, COINIT_MULTITHREADED);
let result = f();
  • Files reviewed: 8/9 changed files
  • Comments generated: 5
  • Review effort level: Balanced

if hwnd == 0 {
return None;
}
let owner_pid: Option<u32> = header.next().and_then(|p| p.parse().ok());
Comment threadrust/Cargo.toml
# Shared Windows.UI.Shell.Tasks integration, re-exported as `shell_tasks` behind
# the `shell-tasks` feature. Standalone + build.rs-free so enabling it does not
# perturb the base SDK; its Windows-only WinRT deps activate only on Windows.
github-copilot-shell-tasks = { version = "0.0.0-dev", path = "crates/github-copilot-shell-tasks", optional = true }
Comment on lines +109 to +111
unsafe {
let _ = CoIncrementMTAUsage();
}
Comment on lines +233 to +248
pub fn deregister_sparse_package(package_full_name: &str) -> Result<bool, SparseError> {
let package_full_name = package_full_name.to_owned();
run_on_mta_thread(move || {
let manager = winrt(PackageManager::new())?;
let operation = winrt(manager.RemovePackageAsync(&HSTRING::from(&package_full_name)))?;
let result = winrt(operation.join())?;
let error_code = winrt(result.ExtendedErrorCode())?;
if error_code.is_err() {
let text = result.ErrorText().map(|t| t.to_string()).unwrap_or_default();
return Err(SparseError(format!(
"sparse package deregistration failed ({error_code:?}): {text}"
)));
}
Ok(true)
})
}
Comment threadrust/Cargo.toml
Comment on lines +33 to +35
[workspace]
members = ["crates/github-copilot-shell-tasks"]
resolver = "3"
@DevGhub007DevGhub007 changed the title Add shared Windows.UI.Shell.Tasks (Forerunner) integration to SDK crateAdd shared Windows.UI.Shell.Tasks integration to SDK crateAug 5, 2026
@DevGhub007
DevGhub007 marked this pull request as ready for review August 5, 2026 02:23
@DevGhub007
DevGhub007 requested a review from a team as a code ownerAugust 5, 2026 02:23
@@ -0,0 +1,34 @@
[package]
name = "github-copilot-shell-tasks"
version = "0.0.0-dev"

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this right versioning scheme ? Can you look at other crates and check the recommended versioning

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@DevGhub007@devGIT28