Config rules don't match commands with global flags (e.g. git -C /path commit)

[berk-karaal]

Description

PR #17 fixed Dippy to show clean descriptions when asking for permission — git -C /some/path commit is displayed to the user as "git commit", not "git -C". This is correct, but it creates a confusing inconsistency:

1. Dippy asks permission for "git commit" (global flags stripped in the description)
2. User adds allow git commit to their .dippy config based on what they saw
3. Next time the same command runs, Dippy still asks for permission — because the config matcher checks against the raw tokens git -C /some/path commit, which doesn't match the pattern git commit

In other words, the description and the config matching use different representations of the same command. The user sees "git commit" but can't write a rule that matches it when global flags are present.

This commonly happens when Claude Code works with worktrees, where git commands are invoked as git -C /path/to/worktree ....

Steps to reproduce

1. Add allow git commit to your project .dippy file
2. Trigger a git -C /some/worktree commit -m "message" command (e.g. Claude Code working in a worktree)
3. Dippy shows the permission prompt as "git commit"
4. Despite the config rule matching exactly what's displayed, Dippy still asks

Reproduction script

# uv run python repro.py
from dippy.core.config import Config, Rule, match_command, SimpleCommand
from pathlib import Path

cfg = Config(rules=[Rule("allow", "git commit")])
cwd = Path("/tmp")

r1 = match_command(SimpleCommand(words="git commit -m test".split()), cfg, cwd)
r2 = match_command(SimpleCommand(words="git -C /some/path commit -m test".split()), cfg, cwd)

print(f"git commit -m test          -> {'MATCH' if r1 else 'NO MATCH'}")
print(f"git -C /path commit -m test -> {'MATCH' if r2 else 'NO MATCH'}")

Output:

git commit -m test          -> MATCH
git -C /path commit -m test -> NO MATCH

Expected behavior

allow git commit should match git -C /some/path commit -m "test". The config matcher should recognize the same command that the description shows the user.

Root cause

_match_words() in config.py joins raw tokens into "git -C /some/path commit -m test" and tries to match against the pattern "git commit *" via fnmatch. This fails because -C /some/path sits between git and commit.

PR #17 added _find_action() to the git handler to skip global flags for description and classification purposes, but this normalization is not applied during config rule matching.

Affected handlers

Multiple CLI handlers define GLOBAL_FLAGS_WITH_ARG / GLOBAL_FLAGS_NO_ARG constants that would be affected: git, docker, auth0, ip.

Environment

• Dippy v0.2.7
• Observed when Claude Code uses worktrees (git -C) or --work-tree

[Djaler]

Same thing for environment variables

For example:

DOCKER_IMAGE=foo:latest docker compose up -d

doesn't matches with

allow docker compose up

[johnnychang-delta]

@ldayton This would tremendously reduce my dippy config length, would love some traction on this, thanks.

[powli]

Following up on @Djaler's point about environment variables — this is a real, distinct gap from the global-flags case, and #137 does not cover it.

Root cause (same spirit as the global-flags bug): _analyze_simple_command strips leading FOO=bar assignments to compute base/tokens, but then matches config rules against the raw words (SimpleCommand(words=words) in analyzer.py). So allow symfony never matches COMPOSE_PROJECT_NAME=app symfony …. Built-in handlers (git, docker) are unaffected because they receive the env-stripped tokens; only commands matched purely by user config rules break.

from dippy.core.analyzer import analyze
from dippy.core.config import Config, Rule
from pathlib import Path

cfg = Config(rules=[Rule("allow", "symfony")])
print(analyze("symfony php foo", cfg, Path("/tmp")).action)          # allow
print(analyze("FOO=bar symfony php foo", cfg, Path("/tmp")).action)  # ask  <-- bug

Why #137 doesn't fix it: its strip_global_flags() early-returns unless a handler exists for tokens[0] (so symfony is skipped), and its retry rebuilds the match input as list(words[:i]) + stripped, which re-prepends the FOO=bar assignment tokens — so even DOCKER_IMAGE=foo docker compose up against allow docker compose up still wouldn't match.

I opened #146 with a focused fix: a step-1.5 retry against the env-stripped tokens when the raw-token match fails. It mirrors #137's two-pass shape (raw tokens first to preserve explicit deny FOO=* cmd rules) and reuses the same _config_match_decision() helper, so the two converge cleanly regardless of merge order.