Vehla 8.0 is not only a fixed set of built-in commands. The Store lets packages add palette commands — and, for trusted native packages, optional workspace and Dock surfaces. The source of truth for building those packages is the MIT-licensed github.com/ibuhs/vehla-extensions repository.
What lives in the repo
The repository is organized for both product users and extension authors:
sdk/typescript—@vehla/store-sdkfor Node.js 20+ command packagessdk/swift— Store SDK, Native UI SDK, Dock Widget SDK, tests, and thevehla-swiftCLIextensions/— complete example packages you can install locallypackages/— versioned ZIP archives for catalog deliverycatalog.json+scripts/build-catalog.py— immutable archive build, SHA-256 checksums, and optional Ed25519 publisher signing
If you want the product-side walkthrough inside Vehla, start with Store and extensions and Developer SDK in the docs.
What an extension can do
The current Store API is optimized for command-driven packages. A package can contain one command or a small toolkit. Commands can:
- Accept palette arguments, selected text, and clipboard text
- Run synchronous or asynchronous JavaScript / TypeScript or Swift work
- Call HTTP APIs with declared network access
- Read and write extension-owned persistent data
- Use Keychain-backed secrets declared in the manifest
- Show declarative native forms before launch
- Return rich native result views with brokered actions
- Copy output, open HTTPS URLs, show messages, or deliver notifications
Each command invocation runs in a separate background process, with a 15-second execution limit and a 1 MB protocol output limit. That isolation is intentional: a bad package should fail as a command, not take down the palette.
Two SDKs, one Store
TypeScript / JavaScript packages use Node and runStoreExtension. You write a handler that receives a typed invocation — package ID, command ID, query, context — and returns a result action or a rich view. Local development installs the SDK with npm install --install-links so Vehla receives a self-contained package without escaping symlinks.
Swift packages build signed arm64 executables. The Swift path adds typed handlers, Codable preferences, confined atomic storage, structured secret-redacting logs, and permission-aware HTTP. The vehla-swift CLI can validate, build, test, package, and code-sign an extension from the terminal.
| Path | Best for | Runtime notes |
|---|---|---|
| TypeScript / JS | APIs, text tools, webhooks, quick prototypes | Node 20+, separate process per invoke |
| Swift executable | Native performance, typed storage, richer diagnostics | Swift 6, signed arm64 Mach-O |
| Native UI workspace | Full SwiftUI/AppKit surfaces inside Vehla | In-process, labeled unsafe, explicit risk acceptance |
| Dock widget | Compact / inline / popup Dock surfaces | Signed in-process widget with persistent storage |
Example packages worth studying
The repo does not ship empty stubs. The examples are meant to be readable product patterns:
- Hello Store — minimal SDK + manifest intro
- Text Toolkit — input precedence, JSON, encoding, UUID, timestamps
- GitHub Workflow — structured args, public API calls, Markdown reports
- Web Inspector — HTTP methods, redirects, headers, TLS, bounded downloads
- Webhook Runner — saved actions, atomic storage, cURL generation
- Developer Security Tools — hashing, Base64, JWT inspection, HMAC
- Notification Lab — brokered notifications and form input
- Swift Hello / Swift SDK Lab — native forms, rich results, preferences, redacted logs
- toolbox-native and news-dock-widget — Native UI and Dock widget paths
A practical first install is GitHub Workflow: clone the repo, install its local SDK dependency, then use Settings → Store → Install Local Package and try ghrepo apple/swift.
Permissions are package-wide on purpose
Capabilities are declared in extension.json: clipboard read/write, selected text, open URL, network access, persistent storage, notifications, and user-selected files. Each capability can be Ask, Allow, or Deny. Secrets are declared in the manifest, stored in the macOS Keychain, and never written into the package directory.
That design keeps the permission story readable for users. It also pushes authors toward focused packages: if commands do not share a domain, split them so you are not requesting network access for a pure text tool.
Security: what Vehla promises, and what it does not
Catalog installs verify HTTPS URLs, archive size limits, SHA-256 checksums, path containment, and — for signed packages — Ed25519 publisher identity with first-use trust and key continuity checks. Native catalog packages must be signed; unsigned native catalog updates are blocked.
What Vehla does not claim: a full security sandbox for JavaScript. Command processes still run under the user account. Capability declarations gate brokered actions; they are not a firewall around every Node or native API. Install only packages you trust, review source for local packages, and treat Keychain-backed secrets as protection at rest — not proof that a malicious extension is safe.
Native UI workspaces and Dock widgets are an even clearer trust boundary. Their signed bundles load in-process so they can present real SwiftUI/AppKit surfaces. Vehla labels them unsafe, warns before install, and requires explicit risk acceptance per package version.
How to try it today
- Install or update Vehla from the download page.
- Open Settings → Store and refresh the catalog, or install a local package from a clone of vehla-extensions.
- Review commands and capabilities before enabling.
- Invoke a keyword from the palette.
- When you are ready to build, copy an example package, keep a stable reverse-domain package ID, and read the SDK README in the repo.
For publishing, python3 scripts/build-catalog.py rebuilds immutable versioned archives and catalog.json. Signed builds use an Ed25519 publisher keypair; native packages fail closed without signing configuration.
Why this matters for Vehla
Built-in commands cover the daily Mac surface. Extensions cover the long tail: your GitHub workflow, your webhook runner, your Dock widget, your company’s internal toolkit. Shipping the SDKs and examples in public is how that long tail stays inspectable instead of becoming a black-box plugin economy.
If you are evaluating Vehla as a platform rather than only as a launcher, this repo is the concrete answer. Clone it, install one example, then decide whether the Store model fits the tools you want on your hotkey.
Repo: github.com/ibuhs/vehla-extensions · Docs: Developer SDK · App: Download Vehla