The Toolkit hosts manager lets you add custom domain-to-IP mappings — like routing api.local to 127.0.0.1 or staging.internal to a specific LAN address — without ever risking corruption of your existing system entries. Every change Toolkit makes is written inside clearly labeled delimiter blocks, keeping toolkit-managed rules fully isolated from anything that was already in your hosts file.
Isolated Blocks
When you add an entry, Toolkit writes it inside a dedicated section:
Entries that existed in your hosts file before you ever used Toolkit are never touched. When you remove an entry or clear all toolkit rules, only the content between the delimiters changes — your pre-existing system rules stay exactly as they were.
On Windows and some Linux configurations, your hosts file is owned by the system and requires elevated permissions to modify. Toolkit detects this automatically via the canWrite flag and will prompt you to approve a privilege escalation (UAC on Windows, sudo on Unix) before making any change. No modification is attempted silently.
Hosts File Locations
Show every domain mapping Toolkit currently manages, plus a summary count of unmanaged entries already present in your system hosts file. The managed flag in each entry tells you whether Toolkit owns it.
Example terminal output:
toolkit hosts add <domain> [ip]
Add a domain-to-IP mapping to the toolkit-managed block. If you omit the IP address, it defaults to 127.0.0.1 — the most common use case for local development domains.
toolkit hosts remove <domain>
Remove a specific Toolkit-managed domain mapping. Only entries inside the toolkit delimiter block are eligible for removal — you cannot accidentally delete system entries this way.
--json Output
toolkit hosts list --json emits a HostsFileStatus object containing both managed and unmanaged entries:
toolkit hosts add --json emits a confirmation object with the domain and resolved IP:
toolkit hosts remove --json emits a confirmation object with the removed domain:
