You can think of PKCE as a “one time password” for a public client. It starts during the init phase, where the client generates a secret value (the code verifier). The code challenge is the hash of that secret, typically a SHA256.
The client sends the code challenge in step 1, so that the authorization server can keep track of it. The code is returned like a normal AC flow, nothing special there. When the client exchanges the code for tokens, it now provides the code verifier. With that verifier, the authorization server can also calculate the SHA256 hash and compare that to the challenge it received during the initialization. If these match, the authorization server now knows that it is dealing with the same client instance as during the initialization of the flow.
The security here depends on two things. First, the client keeps the generated code verifier a secret (storing it locally suffices). Second, hashing functions like SHA256 are irreversible. This means that an attacker that sees a challenge cannot determine what verifier was used to generate that challenge. This implies that even if the attacker obtains a valid authorization code, they will not be able to provide the correct verifier, so the token exchange will fail.
Philippe