Make:

Update 1: It looks like the process respawns itself after you type exit, so Ed's suggestion of typing cat is the best one. So instead of typing exit, just type cat when your phone first boots up; this should render the rogue root shell harmless.

Update 2: I woke up this morning to find that an update was out for the G1 that fixes this. That happened pretty quickly (the last update trickled out to users pretty slowly).

I was freaked out about this awful bug in Android. Basically, there's a root shell running that executes every keystroke you type on the keyboard--as the root user, no less. The proof is simple, as Ed Burnette writes:

open the keyboard tray on your G1, ignore anything you see on the screen, and type these 8 keystrokes: <return>-r-e-b-o-o-t-<return>. Poof, your phone will reboot. This only works on a real phone, not in the emulator, and only with firmware version 1.0 TC4-RC29 and earlier.

Ed suggests typing cat to lock up the shell, but here's a way you can completely shut down the rogue shell. Instead of typing reboot, type exit. That will shut the rogue shell down. Ed's suggestion works by causing the shell to run the cat utility, which simply repeats whatever is fed into this. Because this rogue shell isn't tied to any terminal output, this repeated output won't go anywhere.

Each time you boot the phone, use the cat trick. If you're worried about typing random characters into the phone, press the red key, then the menu key. I've found that you can type these commands on the "Draw pattern to unlock" or "Press menu to unlock" screens. You'll need to do this until T-Mobile pushes out the update that fixes this (based on how the last update rolled out, it seems to take a week or more for them to distribute fixes to everyone).

If you want to see the offending process, run the command ps in the Terminal Emulator application (available for free in the Android Market), and you'll see a list of all running processes on the phone. At least on my phone, the rogue sh process is always started as process id 26. So if you run ps, you'll see something like this (output slightly abridged):

root     25    ... krfcommd

root     26    ... /system/bin/sh

system   27    ... /system/bin/servicemanager

If you had the time and inclination, you could edit the init.rc file that's the source of the problem. The only trouble there is that it's not on a normal filesystem, but in a ramdisk image that's unpacked each time you boot up, so you'd have to get your hands really dirty to make that fix.