I like Yannis's answer, but I just couldn't let a 1 answer question go by. Partly since I think any question may benefit from a diversity of view points. Here's what my escalation process would be.
(Almost) Never Sit in the Chair
If you find your butt in his chair, you can be almost certain something has gone wrong. Do let him drag you back to his workstation, and look over his shoulder, but keep his hands on the keyboard and yours off. I don't care how slow the guy types or whether he can't find the mouse with both hands... it is far, far to easy to give unhelpful help when you are the one with the hands on the keyboard. For a good developer the mind/body connection between self and computer is so tight that many have real trouble explaining every step (particularly the really transformative ones) when they are plugged in directly. Having him type will slow you both down and that's good.
IFF (if and only if) you've worked on this one problem for 20 minutes or more and there's no progress, you MAY consider a hands on solution. At this point, my instinct would be to still go back to your own computer, look into the problem locally, and then when a clue is reached, return to him and repeat the hands-off instruction. If, however, you have a situation where really the only way you can solve it is at his workstation (danger - that's an indicator of risky CM practices) then you can sit down and look, but be sure you are so very clear on what you have changed that you could change it all back.
Teaching should almost never be rote instructions. If you are spewing off a list of commands for him to type or syntax for him to fix, you have a serious skills problem on on your hands and it's probably time to talk to a supervisor. Forgetting or not knowing a single simple command due to a memory lapse is one thing. Being a "baby bird" who can't find a single worm without being hand fed simple action after simple action shows a lack of training and competency.
As you explain the steps of a process, be sure you cover "why" - the mental model for how you solve a problem and the ways you hypothesize, learn and correct your model for how to produce good work is key insight that this person needs to learn. I spend a lot of time on this, and look for a light bulb to go off. If I don't see interest and enthusiasm for learning why I get worried about motivation.
The first time you explain a "why", detail is great.
The second time, reference the first time and ask him to remember. Clean up any mistakes.
The third time, expect he's got it, or that there's a serious learning problem. If it's not clicking, it's time to ask him what he's unclear on.
Expect by the fourth time, he doesn't need any of this, he can just do that part.
Look for Issues - Give Feedback
Keep an outside eye on why he's needed help so many times. If he's rushing, get him to slow down. If he keeps forgetting an important step, point that out and ask him to find a way to remember it before he bugs you. If he has real trouble remembering commands/syntax or with other basics, recommend a book or website he can use. Sometimes we just don't realize we have issues until someone points it out.
You can even give feedback on how soon to call on you. I like the idea of a short sit down every week, so he can collect issues and have help addressing the most difficult - that forces a bit of discipline and organization that may be lacking.
But if your project is high-speed, your team may not be able to wait that long - in a 2 week sprint, that's 2 opportunities to get help. You may, however, want to set a time line or a checklist to have ready before he bugs you. Saying "try for half an hour before you give up, I know you can get it" may actually be all the guy needs. In particular, I've seen newer workers have trouble realizing that they are not a failure just because they experience an hour or two of complete confusion. Also, if there's an easy set of things to check and prep before asking for help, have him be clear on that, and refuse, point blank, if he hasn't done it yet.
When to Raise to Management
There are times when this has to go to management. My rule of thumb is that you should not let yourself be pushed into a position where your work and progress are being sacrificed for his. Whenever that point is hit, your management deserves a chance to be in the loop, becuase it's entirely likely that your work is more important, and the management should have enough insight and control to be able to point that out and expect their guidance to be obeyed.
Here's some other indicators:
Serious skill gap - Needs very specific, very detailed instruction on a tool that is the common standard. Exceptions are granted for legacy equipment or very, very new tools - but if it was on the resume (or so simple as to not be something you put on a resume) - then the person should be able to perform basic commands.
Needs more repetition - You repeatedly explain the same tool, command, process - there seems to be no comprehension when you ask him to repeat your explanation in his own words.
Can't follow guidance - you've given a check list or set mentoring hours but the guy can't stop interrupting you.
Slacking at other times - If this person has needed so much help he's become a nuisance, he shouldn't be someone you see chit chatting or goofing around - he's struggling and he needs time to focus nad learn on his own. Also, be aware of how much help he gets from how many different people - if 6 people are helping him for an hour a day, then he's literally managing only 2 hours on his own!