Context
termulaa's pitch is "your terminal + coding agents next to the webapp you're building." Today you open it in a regular browser tab. That works — but the integration story can be much better with a small browser extension.
What the extension would do
- Open termulaa in a popped-out window or PiP-style split — one click, no manual window juggling.
- Integrate with browser workspaces / tab groups — put the terminal tab into the same group as the webapp it's working on. Switch projects by switching groups.
- Optional: launch a terminal pre-scoped to a path — e.g. a toolbar button that opens a new termulaa session
cd'd into the directory associated with the current browser workspace.
- Optional: surface session status (running agents, exit codes) via extension badge.
Why a separate repo
The extension will need its own toolchain (manifest v3, WebExtension polyfills, packaging for Chrome + Firefox). Keeping termulaa (the server) decoupled from termulaa-ext (the extension) lets each ship on its own cadence and keeps the server small.
Prior work
There's an earlier internal design doc (removed from this repo at initial OSS publish) describing a native-messaging-based extension. That approach tied the extension to a specific Chromium fork; for this project we should use the plain WebExtension APIs + the existing loopback HTTP server, not native messaging.
Status
Scoping. Happy to discuss design in this issue before cutting a new repo.
Context
termulaa's pitch is "your terminal + coding agents next to the webapp you're building." Today you open it in a regular browser tab. That works — but the integration story can be much better with a small browser extension.
What the extension would do
cd'd into the directory associated with the current browser workspace.Why a separate repo
The extension will need its own toolchain (manifest v3, WebExtension polyfills, packaging for Chrome + Firefox). Keeping termulaa (the server) decoupled from termulaa-ext (the extension) lets each ship on its own cadence and keeps the server small.
Prior work
There's an earlier internal design doc (removed from this repo at initial OSS publish) describing a native-messaging-based extension. That approach tied the extension to a specific Chromium fork; for this project we should use the plain WebExtension APIs + the existing loopback HTTP server, not native messaging.
Status
Scoping. Happy to discuss design in this issue before cutting a new repo.