GhostTrack looks up metadata rather than tracking devices
The name and menu labels set the wrong expectation. GhostTrack does not follow a phone, open a GPS feed, or locate a person through cell towers. Its phone option parses a number with the Python phonenumbers package and prints region, timezone, carrier, validity, formatting, and number type. That can help normalize a number. It cannot tell you where the handset is now.
The entire project is 8 files and about 316 lines of source. Its main script offers 4 actions: IP lookup, show your public IP, phone-number lookup, and username lookup. Everything runs through a terminal menu. There are no command-line flags, reusable functions documented as an API, output files, or JSON export. The small size makes the code easy to inspect before use.
IP results come from one plain-HTTP request
The IP option sends the supplied address to http://ipwho.is/ and prints fields from the JSON response. Those fields include country, city, coordinates, postal code, ASN, organization, ISP, domain, and timezone. The map link rounds latitude and longitude down to integers, then opens Google Maps at zoom level 8. That is database geolocation, usually an estimate for a network block, not proof of a device's street address.
Plain HTTP is a poor choice for a research input. Anyone able to observe that connection may see the queried IP address or alter the response in transit. The function also indexes expected fields directly, so a missing timezone.current_time value can crash it. Open pull request 119 proposes a fallback for that exact field, but it had not been merged into the last pushed default branch.
What happened when we ran it
Our sandbox cloned commit a5cb8ad into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Installation finished in 19 seconds, adding 36 packages and consuming 60 MB on disk. The package build succeeded in 7 seconds. Pip-audit reported 0 known vulnerabilities.
There was no test script or target, so tests were skipped. The scan found no CI workflow files, Dockerfile, or tests directory. We did not enter third-party phone numbers, IP addresses, or usernames into the interactive program. The run proves that the 0.2 MB checkout installs and builds in this container; it says nothing about lookup accuracy or the availability of outside services.
That distinction is especially important here because almost every useful result arrives from changing external data. IP records move, phone metadata ages, websites redesign their profile routes, and some services return a friendly 200 page for usernames that do not exist. A successful 7-second build cannot check any of those conditions without a maintained set of fixtures and network tests.
Phone metadata defaults to Indonesia
Numbers without an international prefix are parsed with ID as the default region. The geocoder also requests descriptions in Indonesian. A user who enters a local-format number from another country can therefore start with the wrong assumption. The screen does print validity, possibility, E.164 format, region, and number type, which gives a careful operator clues to inspect.
Open issue 130 says the phone search returned incorrect information, though the report contains no reproducible example. Other issue threads ask for a phone's location, showing how easily the label "Phone Tracker" can be misunderstood. The code never contacts a carrier location service. It reads static numbering metadata from the installed library.
Username matches are only HTTP status guesses
The username loop formats one name into a list of social URLs and sends a GET request to each. A status of 200 becomes a positive match; every other status becomes "not found." There is no site-specific error-page signature, redirect analysis, rate-limit handling, authentication, or response-body check. Snapchat appears twice in the list, and some named services have changed or closed since the script was written.
Each request also lacks a timeout. A slow or blocked site can delay the entire sequential scan, which helps explain the open 2026 pull request aimed at username timeout behavior. Professional username tools maintain per-site rules precisely because a 200 response may be a login page, soft error, bot challenge, or generic profile shell. Every GhostTrack hit needs a human visit and an identity check.
The repository has attention without maintainer movement
GitHub showed 15,821 stars and 123 combined open issues and pull requests on September 30, 2026. Fetching both API pages split that backlog into 92 issues and 31 pull requests. New submissions continued through September, yet the default branch's last push was January 11, 2024. No GitHub release exists, and the repository API reported no license.
That is activity around the project, not evidence that fixes are landing. Current reports include missing modules, incorrect phone information, and many low-information requests containing personal-looking numbers or names. The README offers installation and four screenshots but does not explain accuracy, consent, retention, or legal boundaries. Do not post a target's personal data to the public issue tracker.
GhostTrack is readable enough to teach a beginner how three lookup techniques work, and our 26-second combined install and build makes that lesson easy to start. It is a poor choice for an investigation you need to defend. Use IPinfo CLI for IP data, PhoneInfoga for phone research, or Sherlock for usernames, then document the source and verify each result. Whatever tool you choose, work only with lawful authorization and never call coarse metadata a live location.