For an author, “plugin” and “app” are useful only when they map to a real job. One can retrieve source material, another can help create a visual, and a connected book app can work with accepted manuscript state. This guide separates those jobs, explains the current Plugin Directory terminology, and shows where a connected workflow adds something a normal ChatGPT Project does not.
Start with the current terminology: a plugin is the package; an app is the connection
OpenAI changed discovery language on July 9, 2026. The Plugin Directory is now the primary place to discover workflows across ChatGPT and Codex. A plugin can include skills, apps, and app templates. The app remains the part that connects to an outside service and exposes permitted search, retrieval, interface, or write actions. Existing app connections were not removed by the directory change.
That distinction prevents a common author mistake: treating every listing as if it can safely edit a manuscript. Read the plugin’s included capabilities, then inspect the underlying app’s permissions. A research app may only retrieve files. A communication app may draft or send with confirmation. A custom book app may expose bounded manuscript actions. The workflow label does not erase those differences.
Directory presence answers “how do I discover this workflow?” App permissions answer “what can it actually read or change?” Check both.
What a connected ChatGPT app actually is
Strip away the jargon and a connected app is a permission slip plus a set of tools. You authorize ChatGPT to talk to an outside service, and that service declares a specific list of things the conversation is allowed to do — no more. OpenAI’s Apps SDK is built on the Model Context Protocol, an open standard for exactly this: letting a conversation use an external service’s declared tools and data, under your control.
What makes this matter for writing is the word "durable." A plain conversation produces text that lives in the chat. A connected app lets the conversation reach a durable project — a real book with a saved plan, accepted chapters, and a known position — read what it needs, and write back only what you approve. The talking happens in ChatGPT; the book lives somewhere built to keep it.
The mental model: conversation on one side, project on the other
The clearest way to understand a connected book app is to split every action in two: what happens in the conversation, and what happens in the durable project. You speak; the project keeps. You ask to save a chapter; the project stores it as a version and advances your progress. You come back next week in a brand-new chat; the project tells the conversation where you are. The explorer above walks through the six moves this way, because once you see the split, the whole idea clicks.
This split is also what keeps you safe. Because the durable side only changes when you take an explicit action, the conversation can be as freewheeling as you like — drafting, exploring, discarding — without any of it silently becoming your manuscript. The book advances only when you say so.
Choose an author app by the job it must complete
Authors rarely need one integration to do everything. Research material may live in Google Drive, OneDrive, SharePoint, Box, Dropbox, or Notion. A visual brief may move through Canva or Figma where available. Launch communication may use Gmail or Microsoft Outlook Email. OpenAI’s current documentation names these as possible apps for writing and communication workflows, while warning that availability varies by plan, workspace, role, region, and supported surface.
A durable book workflow is a different category. It needs to distinguish draft text from accepted text, identify the current chapter, keep prior versions, preserve canon and voice constraints, and export a clean manuscript. A general file or email app does not become a book system simply because it appears in the same directory. Match each app to a bounded job, and keep one authoritative place for the manuscript itself.
- Research: retrieve a named source, then verify the claim against the original document.
- Visuals: pass an approved brief, then finish typography and print checks outside the conversation.
- Communication: draft from approved launch facts, then review recipients and wording before sending.
- Manuscript: require explicit acceptance, version history, current-position tracking, and export proof.
What a good book app will not do
A connected app is defined as much by its limits as its powers, and for a book those limits are the point. Review the operator, requested permissions, exposed actions, and confirmation behavior before connecting. A custom MCP app is still third-party software; declared tools and workspace controls reduce scope, but OpenAI explicitly warns that unsafe servers and prompt injection can create risk.
BookWriter’s own product contract is narrower: it does not automatically send the whole manuscript into every conversation, its declared book tools do not request phone contacts, drafting does not save prose, and it does not submit a book to Amazon or another retailer. Consequential actions are bounded and require an explicit author instruction or confirmation. Those are BookWriter-specific promises, not guarantees that should be projected onto every app in a directory.
- Trust first — verify the app operator and server before authorizing a custom connection.
- Permission review — inspect what it can read, what it can change, and which actions require confirmation.
- Bounded context — the app retrieves the status, plan, or chapter a task needs, not the entire book by default.
- Explicit saves — drafting never saves; only your accept action stores a chapter.
- No auto-publishing — it can prepare files, but you upload, price, and submit on the retailer yourself.
The value of a connected app is not that it does more on its own. It is that it does exactly what you authorize, keeps a durable record, and leaves every real decision to you.
Private custom app vs Plugin Directory listing: where BookWriter is today
A developer can build and privately test a custom MCP app without that workflow being approved for public discovery. OpenAI’s current developer-mode documentation also limits full custom write actions to eligible Business, Enterprise, and Edu workspaces on the web, with role and admin requirements. Those facts belong above the conversion pitch because they determine whether a reader can use the connection at all.
BookWriter’s connected experience is a Product preview reached through a private developer-mode connection. It is not listed in the public Plugin Directory. The setup guide covers the current workspace requirement, Developer mode, custom app creation, authorization, and tool scan. If public distribution changes, the availability source and every page that consumes it must change together.
Evaluate an author app with a disposable project before trusting a real manuscript
A directory description is not a workflow test. Create a disposable book with two short chapters, one deliberate continuity fact, one rejected alternative, and no sensitive material. Connect the app with the smallest permissions available. Ask it to retrieve the current position, draft without saving, save only after a clear approval, revise the older chapter, and export the accepted text. The test should reveal exactly which records it reads, which actions change external state, and where confirmation appears.
Then test the failure paths. Cancel a save before confirming it. Interrupt a request and check whether anything changed before retrying. Disconnect the app and confirm that the outside service still holds the project safely. Reconnect and verify that the app resumes from stored state rather than reconstructing the book from the conversation. If the workflow cannot explain whether a timed-out write succeeded, it is not ready for a manuscript you cannot afford to duplicate or overwrite.
Finally, inspect the result outside ChatGPT. Open the saved chapter in the source service, compare it with the approved text, verify that the rejected alternative was not stored as manuscript, and open the export in the program that will receive it next. An author app earns trust through a complete read-draft-approve-recover-export loop, not through an impressive first answer.
Repeat the permission review after an update or reconnect. Capabilities can change, administrators can alter workspace availability, and a new tool may introduce a write action that the original test never covered. Keep the app disconnected when it is not part of the active workflow, remove access you no longer need, and never assume a familiar directory name means the same operator, server, permissions, or confirmation behavior as a previously tested connection.
Write down the tested app name, operator, connection date, granted scopes, exposed write actions, confirmation behavior, and disconnect result. That short record gives the author or workspace administrator something concrete to compare after a change instead of relying on memory or a directory description.
- Use a disposable two-chapter project with one known continuity trap.
- Grant the narrowest permission set and record every confirmation boundary.
- Prove that drafting is non-destructive and saving requires explicit approval.
- Interrupt one write, reconcile the actual state, and retry only when safe.
- Verify the stored text and exported file outside the conversation.