When stripping comments is right
It depends entirely on the task, and getting it backwards is expensive in both directions.
Strip them when the question is about behaviour: find the bug, explain what this returns, write a test. Comments in that context are frequently stale, occasionally wrong, and always billed.
Keep them when the question is about intent: review this, document it, explain why it works this way. There the comments are the most information-dense part of the file.
Doc comments are a special case
Documentation comments — the block form above a function signature — carry the contract: parameters, return type, thrown errors. That is exactly what a model needs to reason about a call site it cannot see.
Keeping doc comments while stripping inline ones is usually the right default for code analysis. It is the option this tool defaults to keeping visible for that reason.
What the stripper is careful about
Comment markers inside string literals are not comments. A URL containing a double slash, or a hash inside a quoted string, must survive. This checks whether the marker sits inside an open quote before removing anything.
It is still a heuristic rather than a parser. Verify the output before sending anything where a corrupted line would send the model down the wrong path.