First off — huge thanks to Daniel and all the contributors for PAI. It's been a great experience, and the work you all have put into this is really appreciated.

Problem

The statusline determines location via IP geolocation (ip-api.com), which returns the wrong city for users behind a VPN, proxy, or corporate network. When the exit node is in a different city than the user's actual location, the statusline shows the wrong city and wrong weather.

settings.json already has a location object with city, regionName, lat, and lon fields, but the statusline ignores it — both the location display and the weather fetch rely entirely on IP geolocation, falling back to hardcoded San Francisco coordinates (37.7749, -122.4194) when the geolocation call fails.

Feature Request

Allow users to set their location in settings.json and have the statusline prefer that over IP geolocation. Specifically:

1. Location display — If settings.json has .location.city and .location.regionName, use those instead of calling ip-api.com
2. Weather fetch — If settings.json has .location.lat and .location.lon, use those coordinates for the open-meteo.com API call instead of coordinates from the IP geolocation cache

IP geolocation would remain the fallback for users who don't configure a location.

Current Workaround

I've patched my local statusline-command.sh in two places to read from settings.json first:

Location display (falls back to IP geolocation if no settings.json location):

if [ -f "$SETTINGS_FILE" ]; then
    settings_loc=$(jq -r 'if .location.city then .location | {city, regionName, country: "United States", lat, lon} else empty end' "$SETTINGS_FILE" 2>/dev/null)
fi
if [ -n "$settings_loc" ]; then
    echo "$settings_loc" > "$LOCATION_CACHE"
else
    loc_data=$(curl -s --max-time 2 "http://ip-api.com/json/?fields=city,regionName,country,lat,lon" 2>/dev/null)
    # ... existing IP geolocation logic
fi

Weather fetch (reads lat/lon from settings.json when location cache is empty — also avoids a race condition where location and weather parallel fetches mean weather can run before the location cache is written):

lat="" lon=""
if [ -f "$LOCATION_CACHE" ]; then
    lat=$(jq -r '.lat // empty' "$LOCATION_CACHE" 2>/dev/null)
    lon=$(jq -r '.lon // empty' "$LOCATION_CACHE" 2>/dev/null)
fi
# Fallback: read from settings.json
if [ -z "$lat" ] || [ -z "$lon" ]; then
    if [ -f "$SETTINGS_FILE" ]; then
        lat=$(jq -r '.location.lat // empty' "$SETTINGS_FILE" 2>/dev/null)
        lon=$(jq -r '.location.lon // empty' "$SETTINGS_FILE" 2>/dev/null)
    fi
fi
lat="${lat:-37.7749}"
lon="${lon:-122.4194}"

This works, but gets overwritten on every PAI upgrade since statusline-command.sh is a system file.

Environment

• PAI v4.0.1
• macOS, VPN active