Configure the Copilot SDK lab environment

The Copilot SDK embeds an agent runtime in your application. It is not a library for sending code completions to the VS Code editor. Application identity, tools, permissions, and lifecycle are your responsibility.

Lab briefing

A local application and test mechanism are separated from a remote connector behind an identity gate.

Original concept illustration (SVG)

Separate local application correctness from authenticated inference.

At a glance	Your route
Level and time	200; 20 minutes (facilitation estimate)
Starting action	Start with synthetic order-status data and the offline application tests.
Learner materials	Download 16-sdk.zip
Workspace	Open the extracted kit root; run the baseline from `.` relative to that root
Expected initial check	The supplied baseline tests pass.
Setup help	Download, extract, local Git and optional GitHub

[!NOTE] Editor access and SDK runtime authentication are separate boundaries.

Concepts · First task · Evidence checklist · Reset

Learning objectives

Prepare local tests without invoking a model.
Identify the runtime/package versions for the selected language.
Separate VS Code, CLI, and application authentication.

Before you start

Use the work-drive setup and enable Copilot. The integrated exercise uses Node 24. A .NET adaptation is optional; LocalDB, SQL Server, Blazor, cloud resources, and database migrations are not required.

Concepts and use cases

Boundary	Responsibility
Development assistant	Helps you author and review application code
SDK client/session	Starts and manages the application’s agent runtime
Application tool	Validates arguments and limits data/side effects
Permission callback	Decides which runtime operation may proceed
Offline test double	Verifies your application contract, not model behavior
Authenticated live run	Tests real SDK integration; consumes account resources

Exercise scenario

You will prepare a small support assistant. It may read only synthetic order-status records owned by the trusted fixture actor. It must not execute shell commands, read arbitrary files, make purchases, or pretend a failed tool succeeded.

Task 1 - Prepare the selected fixture

From the curriculum root:

node scripts/prepare-hands-on.js --lab 16-sdk --destination /Volumes/T9/Dev/oss/workshop-runs/16-sdk

Open the printed directory as the workspace root.
Inspect its README, package manifest, application boundary, and tests.
Run the offline command documented there before installing the optional SDK package. Record both the discovered tests and their exit code.
Do not install packages globally to solve a local import error.

Task 2 - Plan a live SDK run

Read the official SDK setup and authentication pages linked below.
Record the package version declared by the fixture; do not silently substitute latest or a different SDK.
If you choose the optional live exercise, install that package in the disposable copy, using the work-drive cache.
Verify authentication through the documented CLI/SDK flow. With the interactive CLI, start copilot and use /login when prompted; record only success/failure.
Confirm available models rather than assuming a model shown in a screenshot.
Review the permission handler before making a request. Do not use unrestricted approval to make a sample appear functional.

Checkpoint: state whether you validated offline application logic, SDK startup, authentication, or live inference. These are four different results.

Check yourself

Offline tests pass and Copilot works in VS Code, but the SDK application cannot start a session. What does that tell you?

The application has its own authentication path, and it has to be verified separately from the editor. Editor access and SDK runtime authentication are separate boundaries, so a working editor proves nothing about the application.
Copilot is signed in inside VS Code, so the SDK inherits that session and the failure has to be a code bug. The editor sign-in covers editor access only and grants no session to the application runtime, so the failure can still be authentication.
Passing offline tests already validate the SDK integration, so the fault must be the network or the model. Offline tests use a test double to check the application contract, not SDK startup or live inference: those are separate results.

Verify your work

Offline tests can run without credentials or network.
Dependencies and logs stay inside the disposable workspace/work drive.
The application’s allowed data and operations are explicit.
Live access, if attempted, uses the intended account and records failures.
No API key or access token appears in a file, prompt, screenshot, or commit.

Troubleshooting

Symptom	Diagnosis
SDK package missing	Offline checks should not import it; install only for the live step
Editor works, SDK fails	Verify the application’s authentication path separately
Operation denied	Inspect the request and permission policy; do not approve everything
No response or timeout	Record the error, close the session, stop the client

Independent practice

Design the same boundary for .NET: session lifetime, cancellation, tool arguments, permission decisions, and error propagation. Record differences from the Node API; do not claim one language’s API signatures are portable.

Reset

Stop the application in its own terminal, close its session, and revoke any exercise-only credentials. Keep the original curriculum untouched. Remove the disposable copy only after saving redacted evidence.