is a post-launch fix out of scope or a covered defect?

Compare the behavior to the agreed spec, not to the client's current wish. If the thing does what you both signed off on but the client now wants it to do something else, that's a change request, however they label it. If it fails to do what was agreed — breaks, errors, or behaves contrary to the spec — that's a defect you owe. The label 'bug' carries no information; the spec does. Run every post-launch issue through that one comparison and the warranty-versus-new-work split becomes clear even when the client's framing doesn't.

Generally not, if that environment was outside what you committed to. A defect is a failure under conditions you agreed to support; a failure in an unsupported browser, device, or configuration is the work meeting its actual scope and the client wanting that scope widened. Making it work there is new compatibility work, not a fix. The exception is if your contract or the brief implied that environment was in scope, in which case it's a defect. This is exactly why a supported-environment list in the contract is worth writing — it pre-answers this argument.

It depends on your terms, and on judgment. A genuine defect that appears after the warranty period is, strictly, outside the window you committed to, so billing for it can be defensible. But a clear bug in your own work, surfacing not long after the window, is often worth fixing on goodwill — quibbling over a real defect just past warranty rarely pays off in reputation. Reserve strict enforcement for cases well outside the window or where investigating the issue is itself substantial. Inside the window, genuine defects are simply owed.

Call it what it is — added capability, not a repair. If resolving the issue means building behavior the original never had, you're extending the work, not restoring it, and extension is new work regardless of how the request is framed. Separate the two cleanly: if there's also a real defect in the area, fix that as warranty; the new capability you scope and price as an update. Saying 'the current behavior matches what we built — adding this is a small new piece I can quote' keeps you fair on the bug while staying paid on the feature.

For exactly as long as your warranty window says, which is why naming one matters. Without a stated period, 'how long am I on the hook' becomes an open-ended question neither side can answer, and clients reasonably assume longer than you intend. A defined window — a set number of weeks or months during which defects in the delivered work are fixed free — gives both sides a clear boundary. Inside it, real bugs are owed; past it, your terms govern whether a fix is goodwill or billable. Define it once and the timing stops being a recurring negotiation.

Three things: a warranty window, a supported-environment list, and a sentence distinguishing defects from change requests. The warranty window sets how long free fixes last; the environment list defines where the work is promised to function so unsupported-platform issues don't read as bugs; and the defect-versus-change sentence states that fixes restoring agreed behavior are covered while changes to that behavior are quoted. Together they convert nearly every 'is this a bug' standoff into a clause you can point at, replacing an argument about intent with a definition you both already accepted at signing.