While proof assistants typically use constructive mathematics, the Curry-Howard-Correspondence does not necessarily require constructivism.
The important aspect of the correspondence is that the logical rules correspond to the type-checking rules of your programming language of choice.
The "natural" correspondence is constructive, since Curry/Howard were interested in types that were added to the λ calculus to bypass Curry's paradoxon.
However, one can add additional features to the programming language at hand with respective typechecking rules that may correspond to a logical axiom not part of constructive mathematics. While the proof assistants you mentioned, like Coq, simply add these axioms as "uninterpreted symbols" (a feature in the programming language without computation), it is actually possible to support classical reasoning without giving up on a computational interpretation:
call/cc, as seen in programming languages like Scheme.
To see this, it is instructive to first look at the dynamic and at the static semantics of
(call/cc f) + 2 will apply
f to the "outer context". Essentially, the part
(call/cc f) in the whole expression
(call/cc f) + 2 will become a "hole" that is to be filled, which is applied to
(f (λh. h + 2))
Trying to typecheck this, as done in Typing First-Class Continuations in ML, will lead to the type:
This looks eagerly similar Peirce's Law, which is equivalent to the law of excluding middle, the core feature of classical reasoning! So, even when you are allowed to time-travel, you can establish a feature in your programming language that has a computational interpretation while fulfilling the Curry-Howard-Correspondence.
The correspondence itself is "disconnected" from the concrete logic or programming language at hand, i.e., it does not matter whether you look at classical logic, constructive logic, linear logic, minimal logic, ultrafinitist logic, ..., whatever logic and likewise for programming languages.
And moreover, the correspondence itself is "disconnected" from the computation of the programming language, i.e., we can add "compiler intrinsic functions" or "custom axioms without computational meaning" that nonetheless typecheck (after all, not everything has to compute in a proof assistant, since it is not a programming language).
The key point is really that "whatever typechecks in your programming language has an interpretation in (some) logic".
In turn, the correspondence is helpful for proof assistants in the context of whatever logic you are interested in.