Glem AI SDK for Visual Studio Code

Glem AI SDK for Visual Studio Code is the official extension for developing plugins on the Glem platform. It installs and updates the Glem SDK in your plugin workspace, runs the SDK host locally, and builds and deploys your plugin to that host from the editor. An AI assistant connected to your Glem instance helps you plan, write and review plugin code that follows Glem's plugin conventions.

Features

• New plugin projects. Open an empty folder and create a plugin project from the Glem plugin template, the same scaffold GlemCli and Glem Studio use, with the solution, plugin project, development guides and examples ready to build.
• SDK provisioning. Install and update the Glem SDK from your Glem instance or the Glem Platform. Packages are verified before installation, and your plugins and host data are kept across updates.
• Local SDK host. Configure the host database (SQLite by default, Firebird, or SQL Server), start and stop the host, and open it in your browser. Host output appears in the Output panel.
• Build and deploy. Build your plugin project, install it into the SDK host and restart the host in one step.
• AI-assisted development. Work with an assistant that uses your Glem instance's language model and follows the workspace's AGENTS.md and .agents guides. Approval modes control which actions need your confirmation.

Requirements

• A Glem instance and an API key. AI assistance also needs an LLM connector configured on the instance.
• The .NET 10 runtime for database setup and the .NET 10 ASP.NET Core runtime to run the SDK host.
• The .NET SDK, and any Node tooling your plugin uses, to build plugins.
• Node.js and npm on PATH to install the assistant's OpenCode runtime.

Getting started

Install Glem AI SDK from the Visual Studio Marketplace, or install glem-ai-sdk-2.0.2.vsix with Extensions → … → Install from VSIX. Open your plugin folder, or an empty folder for a new plugin, as a trusted local workspace, then select the Glem Code icon in the activity bar.

1. In the Glem SDK view, select Connect to Glem and enter your Glem instance URL and API key. The project saves its instance in server.json, and the extension remembers it with the key, so new projects start connected.
2. For a new plugin, select Create Plugin Project in the Glem SDK view; the extension also offers it when you open an empty folder. Or just describe what you want to build in a conversation: in an empty folder the assistant asks for the company and plugin name and creates the project first.
3. In the Glem SDK view, select Install Glem SDK. In the SDK Host view, select Start host; the SQLite database is set up on first start.
4. After changing your plugin, select Build plugin and restart in the SDK Host view to deploy it to the running host.
5. When it is ready, select Publish my plugin in the Glem SDK view to upload it to your Glem instance's plugin store.
6. To work with the assistant, select Install OpenCode in the Glem SDK view if it is there, then New Conversation, or press Ctrl+Alt+G / Cmd+Alt+G.

Working with the Glem SDK

The sidebar has two views, and each shows only the actions that apply:

The workspace follows the GlemSdkHost layout:

<workspace>/
  server.json
  sdk/
    App/          # Glem SDK runtime and assemblies
    Plugins/      # Installed plugin output
    UserData/     # Persistent host data

New plugin projects. Create Plugin Project works in a folder that is empty apart from version control, editor and container settings, a README or licence, and an SDK. It asks for your company and the plugin name, which give the plugin ID (company.pluginname) and name the solution, project and C# namespace. It then expands the Glem plugin template: the solution and plugin project, AGENTS.md and the .agents development guides, working examples in .example, TypeScript typings in .sdk-types, publish.ps1 and GlemSdkHost.exe. Finally it writes server.json with a SQLite database, adds sdk/, node_modules/ and server.json to .gitignore, runs npm install and downloads the SDK.

SDK source. Your Glem instance decides where the SDK comes from, as in Glem Studio and GlemSdkHost. That instance is Instance.HostUrl in server.json (SDK Settings → Glem instance), or else the instance you connect to. When the instance provides its own SDK (Administration → Plugins → SDK), the SDK is downloaded from the instance and its SHA-256 hash is verified. Otherwise the Glem Platform's latest SDK is used. To download an instance's own SDK, sign in with the API key of the instance you connect to, or set a developer key from the instance's Plugins → Local store. Keys are sent only to that instance, never to the platform. If the instance cannot be reached, a project already on its SDK keeps it and other projects fall back to the platform. Download / Update SDK reports when the installed build is already current.

Updates. Downloads are staged and validated before they replace sdk/App. Plugins and user data are kept, and plugins bundled with the SDK are installed into sdk/Plugins.

Database.

Build and deploy. Build plugin and restart runs dotnet build for the chosen plugin project, copies its built manifest directory into sdk/Plugins and restarts the host. Run any separate front-end build your plugin needs first.

Publishing. Publish my plugin uploads the plugin to the plugin store of the project's Glem instance (Administration → Plugins → Local store) with the project's publish.ps1, as GlemSdkHost's Publish button does: it builds in Release, leaves out the files the Glem SDK already ships, and uploads the package with your developer key from that store. The extension asks for the key the first time and saves it in server.json. A project without publish.ps1 gets the template's copy once; a customised script is never replaced. Uploading an identical package again is skipped, and the store reports the version it already has.

Host. Starting the host writes the database connection and, after a plugin build, PluginDevPath into sdk/App/appsettings.json, then launches Glem on the configured URL. Logs appear in Output → Glem Code. Stopping affects only the host started by this extension; other Glem hosts keep running. After the editor reloads, start the host again from the view.

SDK settings are saved to the workspace's server.json, which may contain database credentials. Keep it out of version control.

AI-assisted development

In a workspace without a plugin project, the assistant creates one before anything else. It asks for your company and the plugin name, then runs the extension's scaffold, which expands the same Glem plugin template as Create Plugin Project; the extension then downloads the SDK. It never writes the solution, Plugin.cs, plugin.json or the project file by hand. In Build and Auto mode you approve the command first.

The assistant runs on OpenCode with your Glem instance as the model provider. Pick the model and the reasoning level beside the mode in the message box. The model list is your instance's AI models that can chat, with Default model for the instance's default. Reasoning is auto (the model's own settings), off, low, medium or high, sent as the OpenAI reasoning_effort; a model whose configuration disables reasoning ignores the level. Each conversation keeps its choice, which applies from the next message, and a new conversation starts from your last choice. Models added to the instance appear in conversations opened afterwards. Project opencode.json, AGENTS.md, .agents guides, skills and MCP configuration apply as usual.

• Each conversation opens in its own editor tab and keeps working while you switch tabs. New Conversation to the Side opens one in a split editor.
• The Conversations view lists the workspace's conversations; select one to resume it. Rename, delete and search are available from the view and the command palette.
• Attach a workspace file, or use Add Selection to Conversation from the editor context menu (Ctrl+Alt+K).
• Enter sends and Shift+Enter starts a new line. The switch beside the keyboard hint changes this to Ctrl+Enter (Cmd+Enter on macOS) to send, with Enter for new lines, in every conversation (glem.sendWith). Ctrl+Enter always sends.
• Attach PNG or JPEG images with the paperclip, by pasting a screenshot into the message box, or by dropping them on it while holding Shift. Images reach the model as image input, so your instance's LLM connector must accept images. Each image can be up to 5 MB, with up to 10 per message, and a message can be images alone.
• Review file changes in VS Code's diff editor, stop a running request, and export a conversation as Markdown.
• Composer commands: /new, /plan, /build, /auto, /allow-all, /compact and /help.

All conversations work on the same workspace files, so changes made in one are visible to the others.

Approval modes

The mode is saved for each conversation and applies from the next message. A run keeps the mode it started with, so when you switch during a run the extension answers that run's approval requests as the new mode would: Allow all approves each one, and Auto those its rules allow. A run that started in Allow all keeps approving until it ends; stop it if you need it to ask.

When a tool needs approval you can allow it once, allow it for the session, or deny it.

Auto allows reads, searches, code navigation, skills, web retrieval and read-only shell commands: PowerShell cmdlets such as Get-ChildItem, Get-Content, Select-Object, Where-Object and Get-Command and their aliases, tools such as ls, cat, grep, rg and find, read-only Git commands such as git status, git diff and git log, and version queries such as dotnet --list-sdks. Each command in a pipeline or script block is checked on its own, so Get-ChildItem | Remove-Item still asks. Auto also asks for redirection (>, including 2>$null), .env files, flags that write files or run programs (find -exec and -delete, git --output and --ext-diff, sort -o, rg --pre), file changes, builds and installs, unfamiliar tools, and access outside the workspace.

OpenCode checks commands, not PowerShell expressions. A statement made only of expressions, such as [IO.File]::Delete('x'), runs without approval in every mode. In Auto, an expression inside an allowed command's script block, such as ForEach-Object { $_.Delete() }, runs as well.

Configuration

Connect to Glem saves the instance in server.json (Instance.HostUrl), and SDK Settings → Developer API key saves the developer key for publishing there too (Instance.DeveloperApiKey), as GlemCli, Glem Studio and GlemSdkHost keep them. An instance chosen separately for the SDK in SDK settings is left as it is. The API key is stored in VS Code SecretStorage. The extension also remembers the instance last connected on this machine with its keys: a project with no instance of its own uses it, and the keys are only ever sent to that instance. New projects ignore server.json in Git, and keys are never passed to the conversation view.

Developing the extension

Open the GlemVsCode folder in VS Code, then:

npm ci
npm run check
npm run build
npm run build:bridge
npm test
npm run test:ui

npm run build:template rebuilds template/PluginProject.zip from GlemCli\PluginProject, the repository's .agents guides and the SDK typings, as Glem Studio's App builder template is built. Packaging runs it first, so a VSIX always carries the current template and guides.

To build the VSIX in one step on Windows, run build.bat (add /nopause in scripts, /ci to reinstall npm packages). It runs npm ci when node_modules is missing, then npm run package, which type-checks, bundles, publishes the SDK bridge and writes glem-ai-sdk-<version>.vsix here. Publishing to the Marketplace is a separate step.

Press F5 with the Run Glem Code launch configuration to open an Extension Development Host. From the repository root, the equivalent is code GlemVsCode first.

Integration checks use real OpenCode processes and a local mock gateway; they do not call a paid LLM:

npm install --prefix .smoke/tools --no-save --no-package-lock opencode-ai@1.19.5
npm run test:smoke
npm run test:vscode
npm run package

test:smoke verifies two independent processes, parallel completions with Glem authentication, streamed events, native Auto approvals (a read-only PowerShell pipeline runs, writes are held for approval), Allow all running writes, .env reads and outside reads without prompts, mode changes, session isolation, process shutdown, and transcript restoration. It reports the shell OpenCode chose; OpenCode uses SHELL when it is set, and Windows PowerShell otherwise. Set GLEM_SMOKE_OPENCODE to use another OpenCode executable. test:vscode downloads VS Code 1.96.4 into the ignored test directory and verifies real editor tabs, a split editor, per-tab Auto persistence, reopening history, and closing one tab while the other remains alive. Set GLEM_SMOKE_VSCODE to use another VS Code executable. UI checks use Playwright Chromium (npx playwright install chromium if needed). The database test runs the bundled helper against a temporary SQLite database.

Implementation notes

• Conversations. Each editor tab owns a separate opencode serve child process with its own loopback port, generated server password, session and XDG data/config/cache/state directories. Closing a tab stops its process tree; closing VS Code stops all extension-owned processes. Separate processes do not create separate working copies.
• Provider. The Glem provider uses @ai-sdk/openai-compatible with base URL <instance>/v1/openai and Authorization: api-key <WorkerApiKey>, matching GlemSdkHost/Core/OpenCodeManager.cs; it does not use Bearer authentication. The configuration reaches OpenCode through its child-process environment. Glem's [#think] / [#end-think] wrappers are removed from displayed, copied and exported responses while their content is kept.
• Approval modes. Auto and Allow all are OpenCode primary agents defined in src/core/provider.ts. OpenCode evaluates their granular permission rules itself. The extension replies to a request automatically only after a mode switch during a run, using the same rules through src/core/permissions.ts. OpenCode's blanket --auto flag is not used.
• SDK downloads. The instance's /api/GlemCore/Sdk/GetLatest is asked first; the platform fallback uses GetLatestSdk / DownloadPackage and GlemSdkHost's UTC download hash. Archives are extracted into staging, archive traversal and symbolic links are rejected, and the host executable is validated before sdk/App is replaced.
• Plugin template. template/build-plugin-template.ps1 is a copy of Glem Studio's AppBuilder/build-plugin-template.ps1 without STUDIO.md. It strips bin, obj, node_modules, package-lock.json and the private-feed .npmrc credential, and vendors @types/unify and @types/portal-light-controllers so npm install needs no private feed. src/core/scaffold.ts ports Studio's PluginProjectScaffolder: [#namespace], [#namespaceL] and [#namespaceLL] are replaced in paths and text files, [#company] in text files.
• Database helper. The bundled .NET helper compiles the existing GlemSdkHost/Core/LocalDbManager.cs implementation with a small headless adapter.
• Packaging includes the compiled extension, browser assets and the .NET database helper; it excludes test sources, node_modules, test profiles and credentials.

References: OpenCode V1 server API, VS Code webviews, and the repository's GlemSdkHost implementation. The OpenCode version is pinned because this client uses its V1 REST/SSE contract.