Fix --line option rejected on PhpStorm 2026.2+

[YoannChabert]

Summary

• PhpStorm 2026.2 (build 262) changed the CLI so --line is now only accepted when a project directory is passed as the first positional argument; without it, PhpStorm exits with unrecognized option: --line
• This silently broke phpstorm:// links generated by tools like the Symfony web debug toolbar (phpstorm://open?file=%f&line=%l)
• Resolves the project root from the target file's git repository and passes it before --line/--column; falls back to the previous behavior when the file isn't inside a git repo

Test plan

• Manually invoked the handler with a phpstorm://open?file=...&line=... URL against a git-tracked file on PhpStorm 2026.2 (PS-262.8665.265) — opens the correct project and jumps to the line
• Confirmed the previous behavior (no project dir) still fails with unrecognized option: --line on this PhpStorm version, reproducing the bug this fixes

[jameskitt616]

And i wondered why it suddenly broke for me

[devnix]

Confirming the breakage on PS-262.8665.325, and that a first positional argument makes --line parse again.

The underlying rule looks broader than "--line needs a project directory". On this build the launcher rejects every long option placed first:

$ phpstorm --line 5 /path/to/file        # rc=1, unrecognized option: --line
$ phpstorm --wait /path/to/file          # rc=1, unrecognized option: --wait
$ phpstorm --temp-project --line 5 file  # rc=1, unrecognized option: --temp-project

--temp-project is documented in --help for exactly that position, so this reads as an argument parsing bug: long options are only parsed once a positional has been consumed. Anything that fills the slot works, which is worth spelling out because each candidate has a different cost.

• Repeating the file path works and jumps to the line, but it renames the open project after the file. I had to rename mine back by hand.
• A directory PhpStorm already knows is the only harmless option. An unknown one raises "Trust and Open Project" and leaves a stray project behind, which a freshly created git repository reproduces, so the git root does not avoid it.

That is my one reservation about git rev-parse --show-toplevel. It works because the git root usually happens to be the project you already have open, not because git is the relevant property. The two diverge in ordinary cases: a project without git, and a monorepo where the open project sits below the git root, which brings back the trust dialog.

Walking up for the nearest .idea tests the property directly, with the git root as a second choice and, failing both, opening the file without --line so the link still does something rather than dying on exit 0:

project=""
dir=$(cd "$(dirname "${file}")" 2>/dev/null && pwd)

d="${dir}"
while [ -n "${d}" ] && [ "${d}" != "/" ]; do
    if [ -d "${d}/.idea" ]; then
        project="${d}"
        break
    fi
    d=$(dirname "${d}")
done

if [ -z "${project}" ] && [ -n "${dir}" ]; then
    project=$(cd "${dir}" && git rev-parse --show-toplevel 2>/dev/null)
fi

if [ -n "${project}" ]; then
    /usr/bin/env phpstorm "${project}" --line "${line}" "${file}"
else
    /usr/bin/env phpstorm "${file}"
fi

Everything above is from PS-262.8665.325 on Linux. I have no older build installed, so I cannot say when the parsing changed. Happy to send this as a patch on top if it is useful.