Allowing more with Lua

Luau was the initial choice in order to improve security thanks to its sandboxing by default. However, it drastically limits plugin capabilities. For instance, reading local files is a standard requirement for many plugins.

Standard Lua is a better choice—losing structural typing, but unlocking far more potential features for users' plugins.

Bundled Plugins

Bundled plugins must be high quality—they should maintain a similar experience to v1 while enabling extensibility.

Some current v1 features add little to no value to the user experience; they might be dropped or kept merely as examples:

• Task Manager: Usually, integrating your agent directly with a remote task manager (like Linear) is more efficient.
• File Viewer: Opening an editor (Ctrl + O) or switching to a shell is usually more practical.
• Automations: I have never really used automations, and some tasks can already be handled by agents (e.g., Claude's /schedule).

On the other hand, some features do require extensibility to support different user workflows:

• Info Panel: Agent metrics must support any provider. This needs to be easily extensible so new users can support their own agents.
• Code Review: Local reviews might need support for publishing to remote servers (GitHub, GitLab, etc.). Subjective and visual settings must also be configurable.

Finally, some core features will require less extensibility, but providing it is still a plus:

• Session List: The current opinionated display might need some changes.
• Agent Main Pane: Same as the session list—tabs and splits might be required for some users.

Adding Custom Plugins

Adding custom plugins is a key feature for Thurbox v2. Users can add custom panes to view and monitor their project service metrics or logs. This is usually hard to support out-of-the-box with bundled plugins.

The first thought would be to handle plugins like skills (as in Claude) or a .gitconfig setup. Users will need both user-level and project-level plugins. Plugins could be loaded from ~/.thurbox/plugins and the local .thurbox/plugins directory. However, Thurbox is also a tool made to handle multiple projects; v1 was path-agnostic—you could run it from anywhere, and the TUI would always be the same.

A second thought would be to provide "plugin profiles," allowing users to switch between different plugin layouts.

Last but not least, we could let users develop their own profile-manager plugins to switch between multiple layouts. This final option might seem like the lazy approach, but it might also be the best one. The Thurbox project should create bundled plugins only based on real user feedback, instead of trying to anticipate user needs.

Keeping Thurbox Consistent

Without locking plugins to hard constraint, and keeping friendly user experience, main core thurbox features must be kept and immutable.

Following displayed info will be kept as mandatory features:

• Top bar, will display thurbox version and thurbox name (same as v1) to provide clean context.
• Bottom bar, will always provide help, settings and theme buttons and will also always provide core navigation shortcuts.

Reload shortcut F10 and performance pane F12 are also part of immutable required options.

v2 Delivery

Due to drastic vision change, v2 is built as a new binary. Both v1 and v2 will cohabit within same repository. v1 patches and improvement are still considered and reapply to v2 if coherent.

As for now, thurbox v2 will be delivered as a new binary (thurbox2) and won't be included within all v1 release process (choco, winget, arch...) until we consider it to be mature enough to supersede thurbox v1.