Even when the change is apparently minor, it can have ramifications. The "one-minute fix" to some CSS class might impact the user interface (UI) on some other page the developer isn't thinking about, or might break important regression tests. This is the very definition of cowboy coding.
More importantly, bypassing the agreed-upon workflow is a recipe for lost productivity, allowing invisible work acting as a drag on the project and reducing overall product quality. "Just this once" creates technical debt, but a culture of "just this once" will eventually break your process. Don't allow that to happen.
No Invisible Work, Ever
Lets say you have a bug on your website. Your developer needs to fix some CSS or something. He estimates it will take him 1 minute to fix.
Your developer is wrong. It may or may not be as easy to fix as he thinks—developers have been known to underestimate tasks, especially if they aren't thinking about how "minor" changes might impact other things in the system—but any task carries real-world overhead such as:
Task-switching overhead. Science tells us that interruptions often require an average of 23 minutes and 15 seconds for the task-performer to recover flow.
Process overhead such as refactoring, unit testing, integration testing, and regression testing.
Other process overhead related to your Definition of Done, including (but not limited to):
Work-tracking overhead, which is essential to ensuring that there is no invisible work, ever.
Perhaps most importantly, unplanned work should never be added to the current Sprint. Some teams handle this by reserving capacity for unplanned work or by having a generic "minor bugs" story, but the best practice is to ensure that all non-critical bugs are prioritized by the Product Owner in a future Sprint.
Tiny stories might be assigned story-point sizes of 0 or 1/2, or they might be lumped together with other minor bugs. I'm a fan of lumping rather than zero-point stories, for the simple reason that no work is ever really "free" and the cost of a dozen zero-point stories is most definitely not zero.
If you use the lumping technique, your next Sprint might include "fix outstanding CSS bugs logged in Jira" as a Product Backlog Item (PBI) sized according to the number and complexity of the bugs and the related overhead of testing them. Unless cowboy coding is a project goal, even "minor" changes should go through the same development/testing pipeline as any other change to maintain product quality and avoid technical debt.