To me, the convenience it brings is not worth the added code complexity and maintenance while you could already do intercept_redirects: '%env(resolve:WEBPROFILER_INTERCEPT_REDIRECTS)%' with WEBPROFILER_INTERCEPT_REDIRECTS=true in your .env.local and achieve relatively the same thing.

I agree with the previous comment. In any case, I'm not comfortable with adding configuration in the web profiler directly.
WDYT @symfony/mergers?

I agree with the added complexity. Without taking a look at the code base, my first idea was that I would be able to add this feature as part as an external bundle.

After seeing this long chain of ifs in WebDebugToolbarListener::onKernelResponse, i saw that it would be harder than I first thought.

Such a feature could be easily inserted in the listener logic if this long if chain was refactored in some kind of Chain of Responsability, the Listener being its Client.
I think this could lower the need for mocks in unit tests, the overall complexity of the actual listener and allow a more extensible debug listener.

Would this be an improvement that appeals to you ?

I'm divided about this (as Fabien, I don't like to add config in the toolbar ... but as upvotes showed, this specific option shortcut would be convenient sometimes).

After thinking about this, I think my vote would be 👎 In addition to the added complexity, this could be used in the future to add more config options directly in the toolbar.

Moreover, this introduces a mismatch between your Symfony config files and the Symfony behavior (e.g. you have false in the intercept option in config/packages/web_profiler.yaml file ... and you click on this option but forget about it ... then redirects are intercepted even if it's false in your config, so you are very confused). Related to this, we'd need 3 states for this option: yes (intercept), no (don't intercept), unset (do what the config file says).

In any case, I appreciate the effort that you put on creating this pull request.

Thank you for this suggestion. I like the idea.
But I think we need to consider the feature "config in the toolbar" and how that is implemented properly before we can tackle this. (ie, to handle weird edge cases that Javier points out)

I suggest to close this PR now and then reopen the idea as soon as we know a good architecture/strategy for options.

Same here, I don't expect content that is not purely informational in this area. Closing, thanks for proposing.