Skip to content

Should we remove the interactive debugger? #3244

Open

Description

@davidism

What if we removed the interactive debugger?

  • Its implementation is ridiculously complex. It's very impressive that it's possible at all.
  • I already had to fix it to work with Flask's contexts, and I'm not sure if we'd ever be able to get it to work with ASGI. Quart doesn't provide it.
  • It's a constant source of (invalid) security reports.
  • The PIN is annoying but not remotely secure.
  • Most users don't realize it also exposes a /console endpoint for arbitrary code without a traceback.
  • Its UI is hard to understand, it's not obvious what's clickable or how to use it.
  • Users end up copying the rich HTML traceback instead of the plain text version.
  • It doesn't work if the app is an API consumed by a JavaScript UI (without some clever detection and rendering in the UI code).
  • I'm not confident it correctly supports newer exception features such as contexts, groups, and notes.

It's nice if you didn't expect a request to fail and want to see why, but you could just as easily set a breakpoint in a real debugger then refresh the page. Perhaps it was more useful in the past, when debuggers and code navigation wasn't as good, and most people were using pdb. But that hasn't been the case for a long time now, PyCharm, VS Code, pudb, and others are all powerful and easy to use. I don't remember the last time I used it to execute code, vs just looking at the traceback and using PyCharm's debugger.

I guess showing the traceback is still useful, although we should make it easier to copy it as plain text. That said, it's already shown in the terminal, I can't think of a time that the dev wouldn't be able to look at that if they see a 500 error in the browser.

Django shows the config and request info, but Werkzeug middleware doesn't have a concept of that, it's only operating on an Environ. Perhaps we could add a hook to display additional info, but that's adding complexity where I want to remove it. And it's still possible to see all that by looking at the code or setting a breakpoint.

Activity

  1. self-assigned this
    on Aug 19, 2026
  2. ThiefMaster commented on Aug 19, 2026

    @ThiefMaster
    Member

    Moving it out of the werkzeug package into a debugzeug (sorry for that terrible name suggestion :D) or werkzeug-debug-middleware package could be an option to avoid people opening vulnerability reports against werkzeug...

  3. davidism commented on Aug 19, 2026

    @davidism
    MemberAuthor

    Moving it out would probably kill it anyway. I don't want to maintain it or see security reports about it, and it would no longer be integrated with flask run/app.run/run_simple so users would need to write a bunch of code to only enable it during dev themselves.

  4. Julien00859 commented on Aug 19, 2026

    @Julien00859
    Contributor

    If I may, Odoo dev here, we removed the debugger from our product 3 years ago with nobody noticing odoo/odoo#115076
    We wouldn't care if it was removed or moved to another package.

  5. davidism commented on Sep 24, 2026

    @davidism
    MemberAuthor

    I asked about this on Mastodon https://mas.to/@davidism/117124012202944312 and got positive reactions there as well.

    @lucaswerkmeister commented that he does find the debugger helpful, mainly because it's built-in and just works as opposed to needing to know about and install a specific IDE or debugger. But he also pointed out that tracebacks are typically enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions