PaperDebugger: an Overleaf copilot that reads your LaTeX and never writes to it

What PaperDebugger actually fixes in the Overleaf loop

Overleaf gives you a collaborative LaTeX editor and nothing else. The usual workaround is to copy a paragraph into a chat window, paste the rewritten text back, and lose the connection between the suggestion and the line it came from. PaperDebugger closes that gap by running as a browser extension inside the Overleaf page. The README describes it as an academic writing assistant that helps researchers "debug and improve their research papers" without leaving the editor, and the feature list is built around that adjacency: chat about the project, insert an AI response with one click, generate comments into the document, and keep a library of prompt templates.

The audience is narrow and worth stating plainly. This is for people who already write in LaTeX and already use Overleaf, not for someone choosing a writing tool from scratch. If your manuscript lives in a local Git repository and you compile with latexmk, the extension has nothing to attach to. The value proposition depends on Overleaf being the surface where the text lives.

The design constraint the README repeats is that PaperDebugger never modifies your project; it reads and suggests. That is a meaningful boundary rather than a marketing line. It means the failure mode of a bad suggestion is a bad suggestion you decline to insert, not a corrupted .tex file you have to recover from Overleaf's history.

Architecture: a Chrome extension over a Go service with two API surfaces

The repository splits into a TypeScript extension under webapp/ and a Go backend under cmd/, internal/, and pkg/. The README's architecture section lists Go 1.24+, Gin for HTTP, gRPC for the API, MongoDB for storage, the OpenAI API for model calls, Protocol Buffers for the service definitions, and JWT authentication with OAuth support. The go.mod file confirms the shape of that stack: gin-gonic/gin, grpc-gateway/v2, openai-go/v2 and openai-go/v3, mongo-driver/v2, and golang-jwt/jwt/v5 are all direct dependencies.

The interesting detail is that both openai-go/v2 and openai-go/v3 appear as direct requires. Two major versions of the same SDK in one module usually means part of the codebase was migrated and part was not, or that the orchestration layer pins an older client than the rest of the service. Either way it is a signal about how the backend evolved rather than a clean single-client design.

Protocol Buffers do real work here. buf.yaml, buf.gen.yaml, and buf.webapp.gen.yaml sit at the top level, and the Makefile's gen target runs buf build, regenerates pkg/gen, regenerates webapp/_webapp/src/pkg/gen, then runs wire gen ./internal. So the HTTP and gRPC surfaces, plus the TypeScript client the extension consumes, are all generated from the same proto definitions. Change a message in proto/ and the extension's client types move with it. That is a coherent choice for a project whose front end and back end must agree on request shapes.

The README credits a "custom MCP-based orchestration engine" behind the Research, Critique, Revision workflow, and points at demo/xtramcp/readme.md. That engine is where the multi-agent claim lives. It is not in the tree you clone.

Installing the extension and pointing it at your own backend

The user path needs no build step. The README's Quick Start says to install the extension from the Chrome Web Store, open any Overleaf project, click the PaperDebugger icon at the top left, and start chatting. There is no command to run and no key to paste for that path.

Self-hosting is where configuration begins. The repository ships a Dockerfile that builds cmd/main.go into dist/pd.exe and exposes port 6060, and the Makefile builds and tags the image as ghcr.io/paperdebugger/sharelatex-paperdebugger. A minimal local run looks like this:

docker build -t paperdebugger .
docker run -p 6060:6060 --env-file .env paperdebugger

The container starts the backend on port 6060. Before it will do anything useful you need the environment the .env.example file defines:

OPENAI_API_KEY=dummy-key
PD_MONGO_URI="mongodb://localhost:27017"
XTRAMCP_URI="" # currently closed-source; Pending release upon stable version

PD_MONGO_URI must point at a reachable MongoDB instance, and OPENAI_API_KEY must be a real key rather than the placeholder. The third variable is the one to read carefully: .env.example states that XtraMCP is currently closed-source and pending release upon a stable version. Setting XTRAMCP_URI to a value does not give you the orchestration engine, because the engine is not published here.

On the extension side, the README gives an unusual configuration path. Open Settings, click the version number five times to reveal Developer Tools, then enter your backend URL in the Backend Endpoint field and refresh the page. The README notes that "Login by Overleaf" only works when you are self-hosting the backend, and that if endpoint errors appear after the refresh you should use Advanced Options at the bottom of the login page to reconfigure. Expect to repeat that dance whenever you move the backend.

Where the closed-source XtraMCP boundary bites

The gap between what the README advertises and what the repository contains is the single most important thing to understand before adopting PaperDebugger. The headline capability is multi-agent orchestration: literature-grounded research, AI-conference review, citation verification, domain-specific revision, described as simulating Research, Critique, Revision. The README links that capability to demo/xtramcp/readme.md and to a custom MCP-based orchestration engine.

The .env.example comment is explicit that this component is closed-source and pending release upon a stable version. So a self-hoster who builds this repository gets the Go service, the proto-defined API, the MongoDB storage, and the OpenAI integration. Whether the multi-agent workflow runs end to end against that service depends on a component you cannot inspect. That is a real limitation, not a documentation nit.

It also creates a licensing asymmetry worth thinking through. The repository is AGPL-3.0, which is a strong copyleft licence with a network-use clause: if you run a modified version as a network service, the licence expects you to offer the corresponding source to users of that service. The orchestration engine that gives the product its distinctive behaviour sits outside that obligation. You are being asked to accept copyleft on the parts you can see while the differentiating part stays closed. That is a legitimate business arrangement, but it means the open-source release is closer to a self-hostable shell than to the full system the paper describes. Anyone evaluating this for a lab or a course should treat the two layers as separate procurement decisions. This is not legal advice; read the LICENSE file and the AGPL-3.0 text against your own deployment.

Maintenance signals and what an upgrade actually costs you

The last push to main was on 2026-07-03, which is recent enough that the repository is not dormant. The release history is thinner than that cadence suggests: v2.12.28 is dated 2026-01-12, and before it the notable entry is v2.9.8, labelled Open Source Release, from 2025-08-27. So the public release tags do not move in step with commits, and a self-hoster pinning a tag is pinning something older than the branch.

The README's Community section is candid in a way that release notes usually are not: it says the team is "actively working to improve long-term reliability, hoping to iron out issues this month." Read that as an acknowledgement that reliability work is in progress. For a tool that reads your manuscript and calls a paid model API, intermittent backend behaviour is the cost you are accepting.

Upgrade cost depends on which layer you touch. The Makefile's gen target regenerates proto output for both the Go backend and the TypeScript client, so a proto change forces a coordinated rebuild of both. The Dockerfile is a plain golang:bookworm build with no multi-stage slim-down, so images are large and rebuilds re-download modules unless your layer cache survives. The go.mod pins Go 1.24.0 with toolchain go1.24.4, which sets a floor on the toolchain in your build environment. None of this is unusual, but the two openai-go major versions mean an SDK bump is not a one-line change.

There is also Makefile.old.full sitting next to Makefile at the top level. That is a leftover, and it is the kind of thing that makes a reader wonder which targets are current. The Makefile itself is the one to read.

PaperDebugger against plain ChatGPT, and when neither fits

The obvious alternative is a general chat assistant. The difference is context and write-back. With ChatGPT you select text, paste it into a browser tab, read a rewrite, then manually reconcile it against your LaTeX. PaperDebugger keeps the conversation attached to the Overleaf project and offers one-click insertion and comment generation, so the suggestion and the document stay in the same window. The README also ships a prompt library, which is the mechanism for encoding recurring review tasks instead of retyping instructions each session.

What a general assistant does better is everything outside Overleaf. If you want to reason about a dataset, draft an abstract from scratch, or work in a language other than LaTeX, the extension's context attachment is a constraint rather than a benefit. And if you are happy pasting text into a chat window and you do not want a browser extension with access to your Overleaf sessions, the general tool is the simpler choice.

There is a third case where PaperDebugger is simply the wrong tool: teams that need the review pipeline to run in their own infrastructure for compliance reasons. The backend is self-hostable, but the model calls go to the OpenAI API unless you change that integration, and the orchestration engine is not published. A lab that must keep manuscript text inside its own network cannot satisfy that requirement by pointing the extension at a local backend alone. Verify the model endpoint path in the code before promising anyone that the data stays in-house.

Who should install PaperDebugger, and what to check first

Use it if you write LaTeX in Overleaf, you want critique and comment generation where the text lives, and you are comfortable with the Chrome Web Store install as the fast path. The extension-only route asks nothing of you beyond a Chrome profile and an Overleaf account, and the read-only guarantee means a bad suggestion cannot damage the project.

Do not use it if your workflow is local LaTeX, if you need the multi-agent pipeline to be inspectable, or if your institution's data policy rules out sending manuscript content to a hosted model API. Self-hosting does not by itself resolve the third point, because the orchestration layer is closed-source per .env.example and the model integration is the OpenAI API per the README.

If you do self-host, the first three things to confirm are mechanical. Click the version number five times in Settings and confirm the Backend Endpoint field appears, then enter your URL and refresh. Confirm MongoDB is reachable at the URI you set in PD_MONGO_URI, since the backend will not start usefully without it. Confirm your OPENAI_API_KEY is a real key, not the dummy-key placeholder. After that, check whether the features you actually want sit behind XTRAMCP_URI, because if they do, they are not in the repository you just built.

Editorial conclusion

Adopt PaperDebugger if you write LaTeX in Overleaf and want reviewer-style critique and insertable comments without leaving the editor; the Chrome Web Store extension is the only path that needs no server. Do not adopt it if you need an auditable multi-agent pipeline today, because .env.example marks XTRAMCP_URI as closed-source and pending release, and do not adopt it if your institution forbids sending manuscript text to a hosted OpenAI endpoint. Before committing, verify three things in your own setup: that the extension's hidden Backend Endpoint field accepts your URL after you click the version number five times, that your MongoDB instance answers on the URI you put in PD_MONGO_URI, and that the AGPL-3.0 obligations match how you intend to run the modified backend.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. PaperDebugger/paperdebugger on GitHub
3. Project website
4. README
5. Releases