Laufen doppelte MCP-Serverregistrierungen zweimal?

Eine doppelte MCP-Registrierung ist selten nur harmloser Konfigurationsballast. Wenn zwei Einträge denselben Server unter unterschiedlichen Namen beschreiben, kann ein Agent zwei Wege zu derselben Fähigkeit erhalten. Bei stdio bedeutet das oft zwei Kindprozesse. Bei einem entfernten Endpunkt können es zwei authentifizierte Verbindungen, zwei Tool-Listen und zwei unabhängige Stellen sein, an denen der Agent den falschen Aufruf ausführt.

Das Ärgerliche daran: Die Konfigurationspriorität löst diese Fehlerklasse nicht. Sie entscheidet nur, was passiert, wenn Einträge beim Namen kollidieren. Sie sagt nicht, ob repo-api, internal-api und my-api drei Bezeichnungen für dieselbe ausführbare Datei und dasselbe Konto sind. Behandle die Identität einer Registrierung als betriebliche Frage, nicht als Namensfrage.

Doppelte Registrierungen schaffen getrennte Ausführungspfade

Zwei verschiedene MCP-Servereinträge können dasselbe Programm zweimal starten, weil der Client Registrierungen als Verbindungsdefinitionen behandelt und nicht als Aliase, die er automatisch zusammenfassen sollte. Die MCP-Transportspezifikation sieht vor, dass ein Client einen stdio-Server als Unterprozess startet und JSON-RPC über dessen Standardeingabe und -ausgabe austauscht. Wenn zwei konfigurierte Einträge denselben Befehl aufrufen, entstehen normalerweise zwei Unterprozesse, jeweils mit eigener Initialisierung und Lebensdauer.

Das heißt nicht, dass ein Agent jedes Tool zwangsläufig zweimal aufruft. Modelle entscheiden selbst, welches bereitgestellte Tool sie verwenden. Das Risiko ist in der Praxis größer: Der Agent kann ähnlich beschriebene Tools aus beiden Registrierungen sehen, im ersten Durchlauf das eine und bei einem erneuten Versuch das andere aufrufen oder beide verwenden, weil ihre Namen unterschiedliche Zuständigkeiten vermuten lassen. Außerdem kann der Serverstart bereits Nebenwirkungen haben, bevor der erste Tool-Aufruf erfolgt.

Ich habe Server gesehen, die bei oberflächlicher Betrachtung passiv wirken. Erst der Blick auf ihre Initialisierung zeigt, dass sie ein Zugriffstoken erneuern, ein Cache-Verzeichnis anlegen, eine lokale SQLite-Datenbank öffnen, eine Abfrageschleife zum Warmhalten eines Index starten oder einen Webhook-Consumer registrieren. Keine dieser Entscheidungen verstößt gegen MCP. Problematisch wird es, wenn ein Team annimmt, ein «MCP-Server» sei ein einziges gemeinsames, passives Objekt.

Ein entfernter Server verändert die Form des Problems, nicht die Notwendigkeit, es zu verhindern. Streamable HTTP ist für einen unabhängigen Serverprozess ausgelegt, der mehrere Clientverbindungen verwalten kann. Das ist nützlich, wenn mehrere Clients beabsichtigt sind. Es bedeutet aber auch, dass der Dienst zwei Verbindungen sehen kann, die beide vorgeben, zum Agenten desselben Entwicklers zu gehören, sofern der Dienst keine saubere Möglichkeit bietet, sie zu unterscheiden und einzuschränken.

Die erste Diagnosefrage ist daher ganz einfach: Erzeugen diese beiden Einträge zwei Ausführungspfade zu derselben externen Instanz? Wenn ja, sind sie doppelt, auch wenn ihr JSON unterschiedlich ist und ihre Namen sinnvoll aussehen.

Ein Servername ist keine Serveridentität

Eine MCP-Registrierung hat mindestens zwei Identitäten, die Teams regelmäßig vermischen.

Die Anzeigeidentität ist der konfigurierte Name, etwa repo-api oder staging-db. Sie ist wichtig, weil der Client sie nutzt, um Tools anzuzeigen und Konfigurationskonflikte aufzulösen. Sie dient Menschen und der Verwaltung durch den Client.

Die Ausführungsidentität bezeichnet das, was die Registrierung tatsächlich erreicht: eine ausführbare Datei mit ihren Argumenten und der relevanten Umgebung oder eine entfernte URL mit ihrem Authentifizierungskontext. Sie betrifft Prozesse und externe Systeme.

In einer aufgeräumten Einrichtung stimmen beide Identitäten überein. Das muss aber nicht so sein. Wer es voraussetzt, sorgt dafür, dass doppelte Einträge bei Prüfungen unentdeckt bleiben.

Betrachte diese Einträge:

{
  "mcpServers": {
    "billing": {
      "command": "python3",
      "args": ["tools/billing_mcp.py", "--account", "prod"]
    },
    "finance-tools": {
      "command": "python3",
      "args": ["tools/billing_mcp.py", "--account", "prod"]
    }
  }
}

Die Namen unterscheiden sich, aber es handelt sich um ein Programm mit denselben Argumenten. Sofern das Programm selbst keine Einzelinstanz erzwingt, wird es zweimal gestartet.

Nun eine weniger offensichtliche Variante:

{
  "mcpServers": {
    "deploy": {
      "command": "./bin/deploy-mcp",
      "args": ["--workspace", "/Users/dev/work/acme"]
    },
    "release-helper": {
      "command": "node",
      "args": ["scripts/mcp-launch.js", "deploy", "--workspace", "/Users/dev/work/acme"]
    }
  }
}

Ein Textvergleich sagt, dass diese Einträge verschieden sind. Ein Vergleich auf Prozessebene kann zeigen, dass der Wrapper dieselbe ausführbare Datei deploy-mcp mit demselben Arbeitsbereich startet. Deshalb braucht eine Konfigurationsprüfung eine Identitätsregel und keinen einfachen Check auf doppelte Zeilen.

Verwende beim Vergleich diese Reihenfolge:

1. Vergleiche den normalisierten entfernten Endpunkt oder die endgültige ausführbare Datei, die der Befehl startet.
2. Vergleiche die Argumente, die Konto, Mandant, Repository, Arbeitsbereich oder Schreibziel festlegen.
3. Vergleiche Arbeitsverzeichnis und nicht geheime Namen von Umgebungsvariablen, die das Verhalten ändern.
4. Vergleiche den Besitz der Zugangsdaten separat. Zwei Einträge, die denselben Endpunkt mit unterschiedlichen Berechtigungen erreichen, sind keine harmlosen Duplikate. Sie sind eine Entscheidung über Berechtigungen, die begründet werden muss.

Vergleiche bei diesem Audit keine geheimen Werte. Du brauchst sie nicht, und wenn du sie in die Prüfausgabe kopierst, entsteht ein weiteres Sicherheitsproblem. Halte fest, dass ein Eintrag BILLING_TOKEN und ein anderer PERSONAL_BILLING_TOKEN verwendet. Kläre anschließend, ob diese Variablen dasselbe Konto autorisieren.

Bereichspriorität kann unterschiedliche Namen nicht bereinigen

Claude Code dokumentiert drei MCP-Bereiche: lokal, Projekt und Benutzer. Einträge auf Projektebene liegen in einer .mcp.json-Datei im Repository, während Einträge im Benutzerbereich projektübergreifend verfügbar sind. Laut Dokumentation wird ein identischer Servername zuerst im lokalen, dann im Projekt- und schließlich im Benutzerbereich aufgelöst. In früherer Dokumentation wurde der Benutzerbereich «global» genannt.

Dieses Verhalten schützt dich vor einem engen Sonderfall: Derselbe Name erscheint in mehreren Bereichen. Vor der üblichen doppelten Registrierung schützt es nicht:

Benutzerbereich:   personal-git      -\u003e /Users/dev/bin/git-mcp
Projektbereich:    repository-git    -\u003e /Users/dev/bin/git-mcp

Beide Namen können sichtbar bleiben, weil kein Namenskonflikt vorliegt. Beide können starten und nahezu identische Tools bereitstellen.

Es gibt noch eine weitere Falle. Ein Entwickler sieht, dass die Projektdatei repository-git enthält, fügt im Benutzerbereich personal-git hinzu, weil das Tool außerhalb dieses Repositorys verfügbar sein soll, und vergisst, dass der Benutzereintrag auch innerhalb des Repositorys geladen wird. Zunächst wirkt alles angenehm. Die Bereinigung wird aufgeschoben, bis ein Tool-Aufruf zwei Audit-Einträge schreibt oder ein Hintergrundprozess dasselbe Zustandsverzeichnis sperrt.

Verwende Bereiche für Zuständigkeiten, nicht für Bequemlichkeit:

• Lege eine Registrierung im Projektbereich ab, wenn das Repository sie benötigt und die Konfiguration sicher geteilt werden kann.
• Verwende den Benutzerbereich für ein persönliches Hilfsprogramm, das in mehreren Repositorys funktionieren soll.
• Nutze den lokalen Bereich für ein privates, repositorybezogenes Experiment, das nicht eingecheckt werden soll.
• Dupliziere keinen Projekteinstieg im Benutzerbereich. Wenn du ihn an anderer Stelle brauchst, rufe ihn entweder nur dort auf, wo die Projektkonfiguration gilt, oder definiere bewusst einen getrennten Eintrag mit anderem Ziel und dokumentiertem Zweck.

Auch eine Überschreibung mit demselben Namen verdient Aufmerksamkeit. Sie erzeugt nicht auf dieselbe Weise zwei aktive Einträge wie zwei verschiedene Namen, kann aber eine Teamkonfiguration hinter einer persönlichen verbergen. Der Agent führt dann Aktionen mit einer privaten ausführbaren Datei oder einem persönlichen Endpunkt aus, während Prüfer annehmen, dass die Repository-Definition gilt. Das ist ein Herkunftsfehler, kein Fehler bei der Prozessanzahl, muss aber ebenfalls behoben werden.

Das Duplikat von der Konfiguration bis zum Aufruf nachweisen

Lösche nicht einfach den ersten Eintrag, der überflüssig aussieht. Stelle die Kette von der Konfiguration über den Prozess bis zur externen Aktion her. So verhinderst du eine sauber wirkende Lösung, bei der stillschweigend der einzige Eintrag mit dem richtigen Konto oder Arbeitsbereich entfernt wird.

Beginne im betroffenen Repository:

claude mcp list
claude mcp get repository-git
claude mcp get personal-git

Anthropic dokumentiert claude mcp list, claude mcp get und claude mcp remove als normale Verwaltungsbefehle. Ermittle mit ihrer Ausgabe jeden sichtbaren Namen und untersuche anschließend die verdächtigen Einträge einzeln.

Notiere für jeden Eintrag in einer temporären Datei fünf Fakten: konfigurierten Namen, Bereich, Befehl oder URL, Argumente sowie das externe Konto oder den Arbeitsbereich, den er erreicht. Füge keine Umgebungswerte ein. Bei einem entfernten Server hältst du Host und Pfad fest, nicht einen Autorisierungs-Header.

Starte anschließend eine kurze Agentensitzung und untersuche die Prozesse, während die Verbindung besteht. Ersetze unter macOS oder Linux billing_mcp.py durch einen eindeutigen Teil des erwarteten Befehls:

ps -ax -o pid,ppid,lstart,command | grep '[b]illing_mcp.py'

Ein doppelter stdio-Start kann so aussehen:

91204 91188 Tue Jul 21 10:14:07 2026 python3 tools/billing_mcp.py --account prod
91219 91188 Tue Jul 21 10:14:09 2026 python3 tools/billing_mcp.py --account prod

Die Prozess-IDs unterscheiden sich. Der Elternprozess kann derselbe Agentenprozess oder zwei verwandte Agentenprozesse sein. Entscheidend ist, dass beide Befehle dieselbe Ausführungsidentität besitzen und ihre Laufzeiten sich überschneiden.

Führe danach einen bewusst sicheren, schreibgeschützten Tool-Aufruf aus. Wähle einen Aufruf mit einem eng begrenzten erwarteten Ergebnis, etwa das Abrufen der aktuellen Konto-ID oder das Auflisten eines bekannten Objekts. Prüfe die Protokolle des Zielsystems, die Serverprotokolle oder dein Aktionsjournal. Wenn du zwei unabhängige Verbindungen, aber einen Aufruf siehst, hast du den doppelten Serverstart gefunden. Wenn du zwei Aufrufe siehst, kläre, ob der Agent zwei Tools ausgewählt, nach einem Fehler erneut versucht hat oder der Server selbst die Arbeit wiederholt hat. Das sind getrennte Ursachen und brauchen getrennte Lösungen.

Die MCP-Lebenszyklus-Spezifikation verlangt eine Initialisierung vor dem normalen Betrieb. Zwei Initialisierungsereignisse reichen als Beleg für zwei Verbindungen. Sie beweisen nicht, dass eine Geschäft­saktion ausgeführt wurde. Sage Einsatzkräften daher nicht «die Bereitstellung lief zweimal», nur weil du zwei Handshakes gesehen hast.

Konfigurationen prüfen, ohne Zugangsdaten zu lesen

Eine nützliche Prüfung auf Duplikate erzeugt für jeden konfigurierten Eintrag einen stabilen Fingerabdruck und schließt geheime Werte aus. Das folgende Skript liest eine oder mehrere JSON-Konfigurationsdateien, extrahiert mcpServers und vergleicht Transport, Befehl, Argumente, URL, Arbeitsverzeichnis und Namen der Umgebungsvariablen. Gib ihm nur Dateien, deren Prüfung du autorisiert bist.

#!/usr/bin/env python3
# save as mcp_duplicates.py
import hashlib
import json
import pathlib
import sys
from collections import defaultdict

if len(sys.argv) \u003c 2:
    raise SystemExit("usage: mcp_duplicates.py CONFIG [CONFIG ...]")

entries = defaultdict(list)

for raw_path in sys.argv[1:]:
    path = pathlib.Path(raw_path).expanduser()
    with path.open() as handle:
        document = json.load(handle)

    for name, server in document.get("mcpServers", {}).items():
        identity = {
            "type": server.get("type", "stdio"),
            "command": server.get("command"),
            "args": server.get("args", []),
            "url": server.get("url"),
            "cwd": server.get("cwd"),
            "env_names": sorted(server.get("env", {}).keys()),
            "header_names": sorted(server.get("headers", {}).keys()),
        }
        encoded = json.dumps(identity, sort_keys=True, separators=(",", ":"))
        fingerprint = hashlib.sha256(encoded.encode()).hexdigest()[:12]
        entries[fingerprint].append((str(path), name, identity))

for fingerprint, matches in sorted(entries.items()):
    if len(matches) \u003c 2:
        continue
    print(f"DUPLICATE EXECUTION IDENTITY {fingerprint}")
    for path, name, identity in matches:
        print(f"  {path}: {name}")
        print(f"    {json.dumps(identity, sort_keys=True)}")

Führe es für die .mcp.json eines Projekts und einen bereinigten Export oder eine Kopie der vom Client verwendeten Konfiguration auf Benutzerebene aus:

python3 mcp_duplicates.py .mcp.json ~/tmp/user-mcp.json

Die Ausgabe sollte so aussehen:

DUPLICATE EXECUTION IDENTITY 64e0e2509d8a
  .mcp.json: repository-git
    {"args":["tools/git_mcp.py"],"command":"python3","cwd":null,"env_names":["GIT_ACCOUNT"],"header_names":[],"type":"stdio","url":null}
  /Users/dev/tmp/user-mcp.json: personal-git
    {"args":["tools/git_mcp.py"],"command":"python3","cwd":null,"env_names":["GIT_ACCOUNT"],"header_names":[],"type":"stdio","url":null}

Diese Prüfung ist bewusst vorsichtig. Sie markiert Einträge mit derselben deklarierten Ausführungsform. Sie kann nicht beweisen, dass zwei verschiedene Wrapper-Befehle nicht in einem Prozess zusammenlaufen, und sie kann nicht beweisen, dass zwei verschiedene URLs nicht denselben Dienst ansteuern. Behandle ihre Ausgabe als Prüfliste, nicht als automatische Löschliste.

Rechne auch mit falsch negativen Ergebnissen, wenn eine Konfiguration einen relativen und eine andere einen absoluten Pfad verwendet. Normalisiere Pfade vor dem Vergleich, wenn dein Team beide Formen nutzt. Verwende dafür ein kontrolliertes Skript, das das Repository-Stammverzeichnis kennt. Führe keine breit angelegte Suche und Ersetzung über Konfigurationsdateien aus.

Zwei unabhängige Instanzen können sich beim Zustand widersprechen

Die teuersten Fehler sind nicht immer doppelte API-Aufrufe. Zwei Instanzen können sich beim lokalen Zustand widersprechen, obwohl sich jede genau so verhält, wie ihre Autoren es erwartet haben.

Nimm einen Server, der einen lokalen Cache mit Repository-Metadaten pflegt. Instanz A startet mit einem älteren Checkout und schreibt Cache-Einträge in ein gemeinsames Standardverzeichnis. Instanz B startet nach einem Branch-Wechsel, liest dasselbe Verzeichnis und hält den Cache für gültig, weil die Datei existiert. Ein Tool-Aufruf liefert nun Daten, die zur aktuellen Sichtweise keines der beiden Prozesse gehören. Der Agent kann anschließend einen völlig gültigen Aufruf für ein veraltetes Objekt ausführen.

Ein anderer bekannter Fehler betrifft einen Warteschlangen-Consumer. Beide Instanzen authentifizieren sich als derselbe Principal und fragen denselben Job-Stream ab. Wenn die Warteschlange Zustellung mindestens einmal garantiert, kann der Umgang mit Duplikaten bereits vorgesehen sein. Fügt der Tool-Autor eine lokale Deduplizierungskarte hinzu, besitzt jeder Prozess seine eigene Karte. Sie verhindert Duplikate innerhalb eines Prozesses, aber nicht zwischen beiden.

Die schlechte Empfehlung lautet hier: «Mach den Server einfach zustandslos.» Sie ist beliebt, weil sie sicher klingt und zustandslose HTTP-Dienste viele Verbindungen gut verarbeiten. Für lokale Tools, die bewusst Caches, OAuth-Erneuerungszustand, Dateiwächter oder Operations-Handles behalten, ist sie falsch. Die richtige Anforderung ist enger: Dokumentiere, ob parallele Instanzen unterstützt werden, welche Ressourcen sie gemeinsam nutzen und was passiert, wenn zwei Instanzen dieselbe Identität verwenden.

Bitte Serververantwortliche, diese Fragen in der README oder der Startausgabe zu beantworten:

• Schreibt der Start lokale Dateien, erneuert er Zugangsdaten oder startet er eine Hintergrundaufgabe?
• Können zwei Prozesse denselben Arbeitsbereich, dasselbe Konto und dasselbe Cache-Verzeichnis verwenden?
• Enthält jeder Tool-Aufruf einen Idempotenzschlüssel, wenn er ein externes System verändert?
• Kann ein Betreiber den Clientprozess oder die Sitzung erkennen, die einen Eintrag erzeugt hat?

Wenn die Antwort auf die zweite Frage nein lautet, mache den Konflikt ausdrücklich sichtbar. Verwende eine Sperre des Betriebssystems, ein eindeutiges Laufzeitverzeichnis pro Prozess oder eine serverseitige Lease. Verlasse dich nicht darauf, dass sich Menschen daran erinnern, die Konfiguration nur einmal einzurichten.

Tool-Duplikate und doppelte Aktionen sind verschiedene Vorfälle

Ein Client kann zwei ähnliche Tools anzeigen, ohne eines davon zweimal auszuführen. Er kann auch über nur ein Tool eine externe Aktion wiederholen. Untersuchungen geraten auf den falschen Weg, wenn beide Ergebnisse als «doppeltes MCP» bezeichnet werden.

Doppelte Tool-Bereitstellung bedeutet, dass zwei Registrierungen sich überschneidende Fähigkeiten ankündigen. Der Agent kann billing_get_invoice von zwei Servern sehen. Das ist ein Risiko für Konfiguration und Prompts. Behebe Registrierungen und Beschreibungen.

Doppelte Ausführung bedeutet, dass zwei lokale Prozesse oder zwei entfernte Sitzungen existieren. Das ist ein Risiko für Verbindung und Lebenszyklus. Behebe den Registrierungspfad, das Verhalten des Servers bei parallelen Instanzen oder beides.

Wiederholte externe Aktion bedeutet, dass das Zielsystem mehr als eine relevante Anfrage erhalten hat. Ursache können doppelte Bereitstellung, Wiederholungslogik, Timeouts, Benutzereingriffe, Serververhalten oder ein Clientfehler sein. Beweise sie mit einer Operations-ID am Ziel und nicht aus der Anzahl der MCP-Prozesse.

Halte während eines Vorfalls diese Einträge zusammen:

Agent run ID:          run-7f3a
Configured name:       repository-git
Server process ID:     91204
MCP connection start:  2026-07-21T10:14:07Z
Tool request ID:       58
Target operation ID:   commit-3a8b

Die Bezeichner müssen nicht genau so heißen. Sie müssen sich über Agent, Server und Zieldienst hinweg verbinden lassen. Wenn eine Ebene keinen Korrelationswert liefern kann, vermerke das im Vorfallsprotokoll, statt die Lücke mit Vermutungen anhand der Zeit zu füllen.

Sallyports Trennung zwischen einem Sitzungsjournal für Agentenläufe und einem Aktivitätsjournal für einzelne Aufrufe ist hier nützlich, weil sie diese Unterscheidung bewahrt. Eine zweite Sitzung oder Verbindung beweist nicht automatisch eine zweite externe Aktion. Die Aufrufeinträge müssen das weiterhin zeigen.

Eine Registrierung entfernen, ohne einen blinden Fleck zu erzeugen

Wenn du ein echtes Duplikat gefunden hast, bestimme vor dem Entfernen eine maßgebliche Registrierung. Der maßgebliche Eintrag sollte einen klaren Besitzer, einen vorhersehbaren Bereich, einen geprüften Befehl oder Endpunkt und eine festgelegte Quelle der Zugangsdaten haben. «Auf meinem Rechner hat dieser Eintrag funktioniert» ist keine Auswahlregel.

Bei einer vom Team verantworteten Integration gewinnt normalerweise der Projekteinstieg, weil er neben der Codebasis geprüft werden kann. Halte Zugangsdaten aus der gemeinsamen Datei heraus. Claude Code unterstützt die Erweiterung von Umgebungsvariablen in .mcp.json, auch in Befehlen, Argumenten, Umgebungsfeldern, URLs und Headern. So sind gemeinsame Definitionen möglich, ohne ein Token einzuchecken.

Für ein persönliches Hilfsprogramm, das projektübergreifend verwendet wird, kann der Benutzerbereich der richtige Ort sein. Entferne den Projekteinstieg dann nur, wenn das Repository für andere Mitwirkende keine gemeinsame Tool-Definition benötigt. Mache aus einer Teamabhängigkeit keine undokumentierte persönliche Voraussetzung.

Führe nach der Änderung diese ruhige Validierungsfolge aus:

1. Speichere den entfernten Eintrag für die Dauer des Tests außerhalb der aktiven Konfiguration.
2. Starte einen neuen Agentenprozess. Bereits laufende Prozesse können alte Verbindungen behalten.
3. Führe claude mcp list aus und prüfe den verbleibenden Eintrag mit claude mcp get <name>.
4. Führe einen sicheren schreibgeschützten Aufruf aus und protokolliere eine Verbindung sowie eine Zielanfrage.
5. Starte noch einmal neu und bestätige, dass die entfernte Registrierung nicht zurückkehrt.

Wenn das Entfernen einen Ablauf unterbricht, stelle nur die maßgebliche Definition wieder her und korrigiere ihren fehlenden Pfad, ihre Umgebungsvariable oder ihre Berechtigungen. Stelle nicht beide Einträge als schnelle Lösung wieder her. Damit würdest du die gerade untersuchte Unklarheit erneut erzeugen.

Doppelte Einträge zu einem Teil der Konfigurationsprüfung machen

Die beste Kontrolle ist eine kleine Prüfregel: Jede MCP-Registrierung braucht einen Besitzer, einen Bereich und eine Ausführungsidentität, die für ihren vorgesehenen Zweck eindeutig ist. Das reicht aus, um die meisten Fehler zu erkennen, bevor Agenten laufen.

Lege die Fingerabdruckprüfung in ein Repository-Skript, wenn das Team .mcp.json versioniert. Führe sie bei lokalen Prüfungen und in der Continuous Integration gegen die gemeinsame Konfiguration aus. Die Einträge eines Entwicklers im Benutzerbereich sieht sie nicht. Nimm deshalb auch claude mcp list in die Einrichtungsliste für Mitwirkende auf, die von merkwürdigem Tool-Verhalten berichten.

Für die Konfiguration im Benutzerbereich führst du außerhalb der Konfigurationsdatei ein kurzes Inventar. Eine Zeile pro Server genügt:

personal-git | user | git tooling across repositories | owner: developer
repository-git | project | repository release workflow | owner: platform team

Wenn beide Zeilen auf dieselbe ausführbare Datei und dasselbe Konto zeigen, muss eine davon entfernt oder ihr Ziel muss bewusst unterschiedlich gestaltet werden. Akzeptiere nicht zwei Bezeichnungen, nur weil eine davon in einem Prompt freundlicher klingt.

Die nötige Disziplin ist überschaubar: ein Weg für einen Zweck, sichtbare Zuständigkeit und der Nachweis, dass eine einzelne angeforderte Aktion genau einen externen Eintrag erzeugt hat. Dann ist ein doppelter Prozess ein beobachtbarer Fehler und kein nächtliches Rätsel hinter zwei nahezu identischen Toolnamen.