This senior programmer was able to answer impeccably all the technical questions in the two interviews

First thing to consider: is your measure of a senior developer solely their ability to answer technical questions? In other words, what is it that, to you, makes a senior profile a senior profile?

Because when I'm hiring senior profiles, I barely ask technical trivia questions unless I particularly feel like they're oddly lacking in that experience. I'm much more focused on how they balance certain natural tensions, e.g. maintaining high code quality standard in the face of a product manager who wants to meet a deadline that's too tight; and I asked about their process of ensuring high quality and avoiding technical debt.

More importantly, I'm looking for a subconscious understanding that these considerations require nuance and balance, and not dogmatic adherence to "the right way of doing things".

(which included writing short pieces of code on the spot)

Building something from scratch is an entirely different skillset than inheriting an existing thing and keeping it both operational and further extending it without causing significant delivery blockers as part of the onboarding process onto the inherited system.

A much more valuable exercise would be to give them an existing (demo) codebase and ask them to fix a few issues, while at the same time giving them the open-ended challenge of identifying technical debt and drafting a proposal as to what they'd change moving forward.

Unfortunately, he wasn't nearly as good as we had thought. He was indeed very good when given narrow, well-focused tasks, but was never able to grasp the bigger picture of our software.

The straightforward truth here is that I have no basis to agree that the developer was unreasonably unable to handle your reasonable code base or development process. It's just as possible that the developer was reasonable unable to deal with an unreasonable code base or development process.

One example of this is that your question focuses on a developer's ability to "handle a large codebase", which subtly excludes the idea that things are easier to maintain when they are decomposed into smaller, individually more digestible components.
You say that the developer couldn't handle a large codebase, but how sure are you that if I ask that developer their opinion, that it would be that the company keeps working with an uncomfortably large codebase?

After nearly two years in our company, he decided to leave (and joined another company).

No mention of any formal processes for them not meeting their requirements + them leaving the company, suggests a possibility that they didn't fail you, you failed them.
They're the one who left you, but you're describing them as if they were the source of the problem that caused them to leave. That math doesn't add up.

Can you detect the weakness of such a candidate?

This phrasing, i.e. an implicit assumption that it was the developer who was defective and you who were in the right, very much aligns with what I have historically seen in companies that struggle to maintain technical excellence (for lack of a better term) in their codebase. I don't see anything in your question that counters this notion.

Overall, my educated read on the topics raised by your question is this:

• Your interview process is faulty as it does not accurately test for the qualities in an application that you will then judge an employee by.
• I cannot definitively judge who is right here, but I do sense a distinct lack of self-reflection as to if the company contributed to the friction between them and the developer. I would recommend a self-reflective moment to align if the expected work (i.e. the large codebase) reasonably matches contemporary coding standards these days - because I get a feeling they might not.
• If an employee does not meet your expectations to the degree that this question implies, then I'm wondering where the action you took is in the two years that they were employed and in your words never displayed an ability you consider to be essential. Either the question is incomplete or it is unclear to me what you were doing to address the issue during their employment.