Cloudflare warp de-routes 127.0.0.1 How to return it?

I'm a web dev and pretty regularly use localhost/127.0.0.1 As you do. The problem is recently I started getting a problem where Cloudflares warp (Its a privacy VPN of sort, with caveats) causes 127.0.01 to stop responding. Even pinging doesn't work.

    ping localhost
PING localhost (127.0.0.1): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
Request timeout for icmp_seq 0
ping: sendto: Can't assign requested address
Request timeout for icmp_seq 1
xping: sendto: Can't assign requested address
Request timeout for icmp_seq 2
ping: sendto: Can't assign requested address

I've tried the route -n flush thing , thinking that maybe its done something hokey to the routing table but even with multiple consecutive runs of it (as is oft suggested) it just doesnt work, and ends up making the internet flakey.

I'm at a loss. It appears to be a common problem too, I asked on reddit and with no answer there where a lot of "me toos" all noting their problems starting around the same time mine started. No answers given.

The only fix is usually to resetart the machine, which is an ugly solution when you have a nest of docker containers and other things that dont like to simply shut down.

Anyone encountered this and have a possible soluton?

edit: For folks in a hurry, the solution from the comments is

sudo ifconfig lo0 -alias 192.0.2.2

See the accepted answer for a breakdown of why this works.

This command will remove the alias from the loopback interface (lo0) and restore the routing table.

sudo ifconfig lo0 -alias 192.0.2.2

More information below:

When disconnecting from the WARP service an alias added by the WARP client persists on the loopback interface. The alias address is 192.0.2.2 on lo0.

Performed some tests while monitoring the routing table with the command route -n monitor

When disconnecting from WARP the following routes are removed from the loopback interface (lo0):

got message of size 124 on Mon Aug 23 21:42:46 2021
RTM_DELETE: Delete Route: len 124, pid: 0, seq 0, errno 0, flags:<HOST,LOCAL,CONDEMNED>
locks:  inits: 
sockaddrs: <DST,GATEWAY>
 127.0.0.1 127.0.0.1

got message of size 80 on Mon Aug 23 21:42:46 2021
RTM_DELADDR: address being removed from iface: len 80, metric 0, flags:<UP>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.0.0.0 lo0 127.0.0.1 127.0.0.1

got message of size 124 on Mon Aug 23 21:10:36 2021
RTM_DELETE: Delete Route: len 124, pid: 0, seq 0, errno 0, flags:<HOST,LOCAL,CONDEMNED>
locks:  inits: 
sockaddrs: <DST,GATEWAY>
 192.0.2.2 192.0.2.2

got message of size 80 on Mon Aug 23 21:10:36 2021
RTM_DELADDR: address being removed from iface: len 80, metric 0, flags:<UP>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 (0) 0 ffff ff lo0 192.0.2.2 192.0.2.2

When running netstat -nr after disconnecting from WARP I can confirm that the route to 127.0.0.1 on the loopback (lo0) interface is missing from the routing table.

The effect of this is that all traffic destined for 127.0.0.1 is sent to the default route after disconnecting from WARP. Output from route -n get 127.0.0.1 below:

route to: 127.0.0.1
destination: default
       mask: default
    gateway: 10.0.0.1
  interface: en0
      flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL>

Reconnecting to the WARP service restores the route to 127.0.0.1 as the route to 192.0.2.2 is restored.

A way to restore the route to 127.0.0.1 on the loopback interface after disconnecting from WARP is to remove the alias from the loopback interface after disconnecting. sudo ifconfig lo0 -alias 192.0.2.2

After removing the alias traffic destined for 127.0.0.1 is properly added back at the loopback interface. route -n get 127.0.0.1

route to: 127.0.0.1
destination: 127.0.0.1
interface: lo0
   flags: <UP,HOST,DONE,LOCAL>

I've had the same issue recently. This usually fixes it:

sudo ifconfig lo0 down
sudo ifconfig lo0 up

I know it's not ideal but it's the workaround I'm using until Cloudflare fixes the WARP client.