Why do I have to cd out of a deleted directory?

Your shell doesn't every time do a cd to the path that it was in during the last command, before executing the next command.

You deleted the current directory and created a directory with the same name, which is not the same directory, just something with the same name/path.

File browsers like Nautilus and Windows Explorer normally "go up" the directory tree if a directory gets deleted on a local file system. However this is not always true for networked file systems, in that case sometimes the deletion does not get noticed and the reappearance could have you ending up in the new directory.

A shell could cd into the current directory before executing the next command, I am not aware of any that do (or can be configured to do so).

On most UNIX-like systems, the "current directory" for a process is stored in the kernel as a file descriptor pointing to that directory. The kernel doesn't actually store the path of the current directory: that information is tracked by your shell.

A filesystem object (file or directory) is only destroyed for good when all filesystem links to it are gone, and there are no file descriptors pointing to that object.

So, if a directory is removed while there's still a process holding it as its current working directory, the process's cwd will keep the directory from being truly deleted. The filesystem links that anchor the directory (its entry in the parent directory, and all of its contents) will be gone, but the directory itself will continue to exist as a sort of "zombie". Meanwhile, you can create a brand new directory at the same location as the old one, which is a completely different filesystem object but which shares the same path.

Thus, when you do cd ../code (or, on many shells, cd .), you are actually traversing the filesystem hierarchy and going to the new directory that resides at the old address.

By analogy, removing a directory would be like forcefully moving a house to the garbage dump (breaking ties to the previous address). If there was still someone living there (using it as their cwd), they'd have to leave before the house could be razed. In the meantime, a brand-new house could be built at the old address.

@Anthon cleared reasons, why it happens
As solution you may use alias, as example:

alias 1234='PROJECT=`pwd`; cd $PROJECT ; ./run' 

aliases for bash are keept in ~/.bashrc

Confirming The current working directory IS based on the inode number, not what you looked up to get there. Since you are using bash, you can use $PWD as follows to cd to the new directory of the same name:

cd $PWD

To illustrate, I made a dummy deploy command:

set -x cd ~/tmp rm -rf code mkdir code echo echo hello from $* > code/run chmod +x code/run 

Created the first deployment, cd'd to code and then checked contents with ls -lai so you can see the inodes:

ianh@abe:~/tmp$ ./,deploy first ++ cd /home/ianh/tmp ++ rm -rf code ++ mkdir code ++ echo echo hello from first ++ chmod +x code/run ianh@abe:~/tmp$ cd code ianh@abe:~/tmp/code$ ls -lai total 12 22945913 drwxr-xr-x 2 ianh ianh 4096 Apr 9 23:12 . 22937618 drwxrwxr-x 14 ianh ianh 4096 Apr 9 23:12 .. 22939455 -rwxr-xr-x 1 ianh ianh 22 Apr 9 23:12 run 

Now run the 2nd deploy

ianh@abe:~/tmp/code$ ../,deploy 2nd ++ cd /home/ianh/tmp ++ rm -rf code ++ mkdir code ++ echo echo hello from 2nd ++ chmod +x code/run 

And check the directory contents ... now there isn't anything in the directory! not even '.' and '..'! From this you can see that bash is not using the '..' directory entry when you run cd .. since '..' no longer exists - I presume its part of its $PWD handling. Some other/older shell's don't handle cd .. in this situation, you have to cd to an absolute path first.

ianh@abe:~/tmp/code$ ls -lai total 0 

Cd to $PWD and try again:

ianh@abe:~/tmp/code$ cd $PWD ianh@abe:~/tmp/code$ ls -lai total 12 22945914 drwxr-xr-x 2 ianh ianh 4096 Apr 9 23:12 . 22937618 drwxrwxr-x 14 ianh ianh 4096 Apr 9 23:12 .. 22939455 -rwxr-xr-x 1 ianh ianh 20 Apr 9 23:12 run ianh@abe:~/tmp/code$ ./run hello from 2nd 

Note how the inode for the current directory (.) changed?

If your deploy script moved the old directory to some other name, eg mv code code.$$ in the ,deploy script above, then ./run would work, but until you use cd $PWD you would be running the old code, not the new.

ianh@abe:~/tmp/code$ ./run hello from 2nd ianh@abe:~/tmp/code$ ../,deploy 3rd ++ cd /home/ianh/tmp ++ '[' -d code ']' ++ mv code code.9629 ++ mkdir code ++ echo echo hello from 3rd ++ chmod +x code/run ianh@abe:~/tmp/code$ ./run hello from 2nd ianh@abe:~/tmp/code$ cd $PWD ianh@abe:~/tmp/code$ ./run hello from 3rd 

Deploying using capistrano has the same issue (They have a symlink from the name current to the current release), so I use aliases to cd to the production/staging areas as well as set RAIL_ENV appropriately:

alias cdp='export RAILS_ENV=production; echo RAILS_ENV=$RAILS_ENV ; cd /var/www/www.example.com/current' alias cds='export RAILS_ENV=staging; echo RAILS_ENV=$RAILS_ENV ; cd /var/www/staging.example.com/current' 

What I assume is that the path is what identifies the directory.

The path to something is how you get there, not the thing itself. The path to your bed may be through your room, but once you are in bed, if someone picks it up and carries it outside, you are no longer in your room.

^{Not a self-contained answer, but I have an additional point, which the commenting margin was too small to contain.}

To get a better feel for the idea that a directory in the relevant file systems is more than just a path, try moving another process's current working directory: in one shell, start an interactive Python session:

$ python >> import os >> os.getcwd() '/home/you/hocus' 

Then, go to another shell and move that directory:

$ cd /home/you $ mv hocus pocus 

Back to the original one:

 $ python >> import os >> os.getcwd() '/home/you/hocus' >> os.getcwd() '/home/you/pocus'