Developing plugins

A plugin is a bundle loaded by Textual and can interact with the app more deeply than a script. That access also makes compatibility and trust important: a plugin is executable code running as part of your client.

Target the actual Textual build

Use the headers and build configuration for the release you want to support. The Textual 7.2.4 release notes explicitly state that plugins built for 7.2.3 need updating for 7.2.4 after legacy interfaces were removed.

Check the target architecture, signing requirements, framework dependencies and sandbox behavior rather than assuming that a tutorial written for an earlier release will still compile unchanged.

The protocol reference

The 2016 plugin API reference contains the protocol and concrete payload types for user/server input, new messages, and JavaScript interaction. Its original method signatures and threading notes are preserved, but the current app's headers take precedence when an interface has changed.

The Textual 6 migration notes remain useful when updating an older plugin, and the original plugin overview links to the archived basic tutorial PDF.

Test failure cases as well as loading

Check plugin behavior during reconnects, bulk history processing, closing views, and malformed input. Follow the documented main-thread requirements when interacting with AppKit or WebKit, and avoid heavy work in message callbacks that may run many times during a history load.

For a simple custom slash command, a script may be easier to maintain than a plugin. If you only want to change the chat presentation, start with a style.