Steward v3 runs a command palette inside the page instead of a popup

The command box is an iframe injected into the page, not a browser popup

Steward is a command launcher for Chrome, and the v3 rewrite is where its interesting design choice sits. Pressing Command+J or Ctrl+J does not open a browser level popup. It injects a command box into the current page as an iframe, with a filter field, arrow key selection and Enter to run. The extension popup is a separate thing: Command+K or Ctrl+K opens the small extension icon window, which contains a way into the settings. Separating the two lets the launcher work in the context of the page you are on, so its commands can act on the document you are looking at rather than on the browser as a whole. The implementation is a Chrome extension built with Manifest V3, and the v3 source is a TypeScript and React project served by Vite, styled with Tailwind and DaisyUI. Notably, the v3 build does not include a new tab feature, and the manifest configuration lists neither a new tab nor any chrome_url_overrides.

Five built-in commands read the DOM of the page you are on

The command list is where the value of an in-page launcher becomes concrete. A current page information command shows the title, the URL, and its host, path, search and hash components, along with any selected text, and picking an item copies it and closes the box. A page links command collects the anchors on the page through the a href selector, capped at 80 entries, and choosing one clicks that link in the current page before closing. A page outline command lists the h1 to h6 headings and scrolls to the one you select. A history command lists recently visited pages and opens the chosen one in a new tab, and a bookmarks command does the same for recently added bookmarks. Alongside these there are commands to open the settings and to close the box. The cap of 80 links is a real design decision: it keeps the list responsive on a large page, and it also means the command is not a complete link picker for pages with more anchors than that.

Two settings switches decide how eagerly the extension injects itself

The settings page has a general section and an about section, and the general section holds two switches. The first is a speed first option. When it is on, the command box is injected as soon as the page loads, which makes the shortcut feel instant at the cost of doing work on every page. When it is off, the extension waits until you press the shortcut the first time before injecting, which keeps browsing lighter at the cost of a small delay on the first use. The second switch remembers the last command, and when it is on, reopening the box pre-fills what you typed last time. The input is written to extension storage with a debounce, so the value is not written on every keystroke. Both settings are persisted to storage once you save the page, so the behaviour follows the profile rather than the session. The point of the speed first switch is that it is the only thing in this extension that changes how aggressively it touches the pages you visit, and it is worth understanding before leaving it on for every tab.

Building the extension means installing, copying icons and loading an unpacked directory

The development instructions are concrete and short. The v3 code lives in its own directory, so you move into it and install the dependencies.

cd v3
npm install

Next comes the step that is easy to miss, copying the extension icons from the older v2 tree into the v3 public img directory, otherwise the extension builds and loads without any icon.

cp ../v2/extension/img/icon16.png ../v2/extension/img/icon48.png ../v2/extension/img/icon128.png public/img/
npm run build

After the build, you open chrome://extensions in Chrome, choose to load an unpacked extension, and select the v3 dist directory. For iterating, the dev script runs a Vite build in watch mode, so a file change triggers a rebuild rather than a hot reload in an open page.

npm run dev

The build itself is a TypeScript compile followed by a Vite build, and the packaging step named prod runs the build and then a Node script called pack.mjs, which presumably produces the archive you would upload to a store. The extension is bundled with a Vite plugin for web extensions and uses the Chrome type definitions, so the code is typed against the browser API rather than loosely typed.

The v2 tree stays untouched while logic is ported piece by piece

The repository carries two implementations, and the README is explicit about how they relate. New features and the Manifest V3 migration both happen under the v3 directory, and the older v2 code is not modified. When logic is later moved over from the v2 extension directory, only the parts that are actually needed are ported, and they are converted to React along the way. Two things are dropped in that conversion: eval, and the ability to execute custom plugins. That is a meaningful restriction to note, because a launcher whose power comes from letting users run their own scripts is a different product from one that only exposes built-in commands. The v3 manifest also drops the new tab override, so the project is moving toward a narrower, more predictable surface: a command box that appears where you are, plus a settings page, plus a small popup entry point. The v3 directory also carries its own manifest configuration, with no new tab entry and no chrome_url_overrides.

The package version and the release tags disagree by several years

The project version in the v3 package manifest reads 5.0.0, while the releases attached to the repository are 4.1.1 from 2021-01-07, v2.6 from October 2017 and v2.5.5 from September 2017. The repository listing also reports no licence identifier, and the LICENSE question is not answered in the README, so anyone who wants to fork or redistribute the extension has to raise that with the maintainer directly. The last push was on 2026-09-01, and the repository is not archived, so the rewrite is being worked on even though the tags have not moved. Two supporting signals suggest an active, if small, project: the repository includes a docs directory and a docs-website directory with VitePress scripts for development, building and preview, and a vercel.json, which points to a published documentation site, alongside the homepage at oksteward.com. For a user, the honest summary is that the current code lives on the default branch and the packaged versions in the store are likely older than what you would build yourself.

Editorial conclusion

Steward v3 suits someone who lives in the keyboard and wants one palette for page information, links, headings, history and bookmarks without leaving the tab, and for developers who want a small React example of an in-page iframe command surface on top of the Chrome extension APIs. It does not suit anyone who wants a polished, signed extension from a store, since the repository publishes no store listing guidance and the last tagged release is 4.1.1 from 2021-01-07, and it does not suit people who need the new tab override that the v3 build deliberately drops. Verify three things before you rely on it: that the icons have been copied into the v3 public img directory, because the build will load without them and the extension will look broken, that the licence situation is acceptable, since the repository listing reports no licence identifier, and that the dev server workflow, which is a Vite watch build rather than a hot reload, fits your editing habits. The last push was on 2026-09-01, so the rewrite is being worked on.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. solobat/Steward on GitHub