If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Ji4n1ng/OpenInTerminal shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 15 active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 74% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Ji4n1ng/OpenInTerminal repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Ji4n1ng/OpenInTerminal.

What it runs against: a local clone of Ji4n1ng/OpenInTerminal — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Ji4n1ng/OpenInTerminal | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 506 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Ji4n1ng/OpenInTerminal. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Ji4n1ng/OpenInTerminal.git
#   cd OpenInTerminal
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Ji4n1ng/OpenInTerminal and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Ji4n1ng/OpenInTerminal(\\.git)?\\b" \\
  && ok "origin remote is Ji4n1ng/OpenInTerminal" \\
  || miss "origin remote is not Ji4n1ng/OpenInTerminal (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "OpenInTerminal/AppDelegate.swift" \\
  && ok "OpenInTerminal/AppDelegate.swift" \\
  || miss "missing critical file: OpenInTerminal/AppDelegate.swift"
test -f "OpenInTerminal.xcodeproj/project.pbxproj" \\
  && ok "OpenInTerminal.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: OpenInTerminal.xcodeproj/project.pbxproj"
test -f "OpenInTerminal-Lite/OpenInTerminal-Lite/main.swift" \\
  && ok "OpenInTerminal-Lite/OpenInTerminal-Lite/main.swift" \\
  || miss "missing critical file: OpenInTerminal-Lite/OpenInTerminal-Lite/main.swift"
test -f "OpenInTerminal-Lite/OpenInTerminal-Lite/Error.swift" \\
  && ok "OpenInTerminal-Lite/OpenInTerminal-Lite/Error.swift" \\
  || miss "missing critical file: OpenInTerminal-Lite/OpenInTerminal-Lite/Error.swift"
test -f "OpenInTerminal.xcworkspace/contents.xcworkspacedata" \\
  && ok "OpenInTerminal.xcworkspace/contents.xcworkspacedata" \\
  || miss "missing critical file: OpenInTerminal.xcworkspace/contents.xcworkspacedata"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 506 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~476d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Ji4n1ng/OpenInTerminal"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenInTerminal is a macOS Finder toolbar app (and extension) written in Swift that lets users right-click a folder in Finder and instantly open it in their preferred terminal emulator (Terminal, iTerm, Hyper, Alacritty, kitty, Warp, WezTerm, Tabby, Ghostty) or text editor (VS Code, Sublime, Xcode, etc.). It also supports opening selected items in custom apps like GitHub Desktop or Fork via a single click. Multi-target Xcode monorepo with separate projects: OpenInTerminal-Lite/ and OpenInEditor-Lite/ folders each containing their own .xcodeproj, plus legacy OpenInEditor-Lite/. Each target includes localization files (.lproj/Localizable.strings), entitlements for Finder extension sandboxing, and Core functionality in Swift. The 'Lite' variants are command-line focused; the full OpenInTerminal variant adds GUI preferences and keyboard shortcut support.

macOS developers and power users who spend time in Finder and want to eliminate the friction of manually navigating to the same directory in their terminal. Specifically useful for those using multiple terminal emulators or editor IDEs who want quick context-switching without typing paths.

Actively maintained and production-ready. The repo shows a polished feature set with support for 9+ terminal apps and 20+ editors, multi-language localization (English, Chinese, French, Russian, Italian, Spanish, Turkish, German, Korean), and a clear divide between full-featured and 'Lite' variants. Travis CI is configured, and the project is distributed via Homebrew and GitHub releases.

Low risk for stability but single-maintainer (Ji4n1ng). The codebase is pure Swift with minimal external dependencies (none visible in file list), reducing supply-chain risk. macOS-specific APIs (Finder integration, Launch Services) could break with OS updates. No visible test directory structure suggests limited automated test coverage. The project appears maintained but dependent on one person for updates.

The repo file structure shows parallel maintenance of three main variants (OpenInTerminal, OpenInTerminal-Lite, OpenInEditor-Lite), with recent additions of support for modern terminal emulators (Warp, WezTerm, Tabby, Ghostty). Multi-language support is comprehensive. The pull request template and GitHub issue templates are in place, suggesting active community engagement. No specific recent commit data is visible, but the breadth of supported apps suggests ongoing refinement.

git clone https://github.com/Ji4n1ng/OpenInTerminal.git
cd OpenInTerminal
open OpenInTerminal-Lite/OpenInTerminal-Lite.xcodeproj
# Or for the full version with preferences:
open OpenInTerminal/OpenInTerminal.xcodeproj

Then build and run in Xcode (⌘B to build, ⌘R to run). For installation via Homebrew: brew install --cask openinterminal.

Daily commands: Build in Xcode: xcodebuild -scheme OpenInTerminal-Lite -configuration Release in OpenInTerminal-Lite/ directory, or use Xcode UI (⌘B). The app installs as a Finder extension and activates via toolbar icon. No background server or dev server required; it's a native extension.

• OpenInTerminal/AppDelegate.swift — Main application entry point that initializes the app, manages the Finder toolbar integration, and orchestrates terminal/editor launching workflows.
• OpenInTerminal.xcodeproj/project.pbxproj — Root Xcode project configuration defining build targets for the main app, Finder extension, and helper executable—essential for understanding the multi-target architecture.
• OpenInTerminal-Lite/OpenInTerminal-Lite/main.swift — Entry point for the lightweight version; demonstrates the minimal implementation pattern used across lite variants for bundling with Finder.
• OpenInTerminal-Lite/OpenInTerminal-Lite/Error.swift — Core error handling model shared across lite variants; defines how terminal/editor launch failures and permissions issues are reported.
• OpenInTerminal.xcworkspace/contents.xcworkspacedata — Workspace configuration coordinating multiple Xcode projects (main app, lite versions, Finder extension) into a cohesive development environment.

• AppDelegate (Main App) — Initializes app, registers Finder toolbar, stores user preferences (preferred terminal/editor), and

Add Support for a New Terminal Emulator

1. Define a new terminal variant enum case in the core terminal detection logic (OpenInTerminal/AppDelegate.swift)
2. Implement terminal launch logic by app bundle identifier (e.g., com.warp.dev for Warp) (OpenInTerminal/AppDelegate.swift)
3. Add localized display name to English and other language string files (OpenInTerminal-Lite/OpenInTerminal-Lite/en.lproj/Localizable.strings)
4. Update user preferences UI to include the new terminal in selection dropdowns (OpenInTerminal/AppDelegate.swift)

Add a New Language Localization

1. Create a new language project folder (e.g., ja.lproj for Japanese) (OpenInTerminal-Lite/OpenInTerminal-Lite/ja.lproj/Localizable.strings)
2. Copy keys from English Localizable.strings and translate values (OpenInTerminal-Lite/OpenInTerminal-Lite/en.lproj/Localizable.strings)
3. Repeat localization folders in OpenInEditor-Lite and main OpenInTerminal app for consistency (OpenInEditor-Lite/OpenInEditor-Lite/ja.lproj/Localizable.strings)

Create a New Lightweight Variant (e.g., OpenInBrowser-Lite)

1. Duplicate OpenInTerminal-Lite folder structure and rename to OpenInBrowser-Lite (OpenInTerminal-Lite/OpenInTerminal-Lite.xcodeproj/project.pbxproj)
2. Update Error.swift to define browser-specific error cases (OpenInTerminal-Lite/OpenInTerminal-Lite/Error.swift)
3. Modify main.swift to detect and launch browser apps instead of terminals (OpenInTerminal-Lite/OpenInTerminal-Lite/main.swift)
4. Register new variant in workspace and update root project to include it in builds (OpenInTerminal.xcworkspace/contents.xcworkspacedata)

• macOS Finder Toolbar Integration (FSEvents/Finder Extension) — Enables seamless one-click access to terminal/editor from Finder without separate window; native macOS experience via toolbar button and context menu.
• Swift & Cocoa/AppKit — Native macOS development language; direct integration with Finder APIs, System Events for app launching, and macOS application lifecycle management.
• Helper Executable Pattern (OpenInTerminalHelper) — Isolates privileged operations (directory traversal, app launching) from main app; improves security and allows operation without full app launch overhead.
• Xcode Workspace with Multiple Targets — Enables parallel development of full-featured app, lightweight variants, and Finder extension with shared code via embedded frameworks.
• Multi-language Localization (.lproj folders) — Supports global user base; Xcode's native i18n system handles language selection automatically per system locale.

• Separate full app (OpenInTerminal) vs. lightweight variants (OpenInTerminal-Lite, OpenInEditor-Lite)

  • Why: Lite variants are bundled with Finder extension and have minimal overhead; full app provides richer UI and preferences. Variants cater to different user needs (power users vs. minimal install).
  • Consequence: Code duplication across variants; localization and new features must be maintained in multiple places. Trade-off between simplicity (single project) and user experience (optimized deployments).

• AppleScript-style open commands (open -a Terminal <path>) vs. direct NSWorkspace API

  • Why: External command invocation is more reliable across macOS versions; less likely to break with OS updates to internal APIs.
  • Consequence: Slightly higher latency and process overhead; less direct control over app launch parameters. Mitigated by helper executable pattern.

• Hardcoded list of supported terminal/editor bundles (Terminal, iTerm, Hyper, Alacritty, kitty, Warp, WezTerm, Tabby, Ghostty)

  • Why: Provides predictable, tested launch behavior for popular terminals; avoids attempts to launch incompatible or non-terminal apps.
  • Consequence: New terminals require code changes; users with obscure terminals must contribute patches. Extensibility lower than plugin architecture, but maintainability higher.

• Cross-platform support: macOS-only (relies on Finder, FSEvents, and AppleScript)
• Real-time file monitoring: No daemon or background service; action is purely on-demand via Finder interaction
• Terminal multiplexing or session management: Launch only; does not manage existing terminal windows or shells
• Plugin or scripting API: Does not expose extensibility for third-party terminal integrations without code contribution
• Authentication or privilege escalation: No sudo/admin elevation; operates with user's current permissions

Finder Extension Sandboxing: The app runs in a restricted sandbox; file access and app launching must be explicitly declared in .entitlements files. Any new terminal or app support may require entitlements updates. Launch Services Limitations: Not all third-party apps are discoverable or launchable via Launch Services; some custom apps may silently fail. macOS Version Compatibility: Finder extension APIs have varied across macOS versions (10.15+); test on multiple OS versions. Localization Strings: Strings must be added to all .lproj/Localizable.strings files or UI will show untranslated keys; the build doesn't warn if a language is incomplete.

• Finder Extensions / Quick Actions — OpenInTerminal is implemented as a Finder extension (right-click toolbar action); understanding Apple's extension architecture and sandboxing model is essential to extend or debug the app.
• Launch Services and Bundle Identifiers — The app uses macOS Launch Services APIs to discover and launch third-party apps (Terminal, iTerm, etc.) by bundle ID; this is the core mechanism for locating installed apps.
• App Sandboxing and Entitlements — Finder extensions run in a sandbox; the .entitlements files explicitly declare what file system and inter-process communication capabilities the app needs, and violations will silently fail.
• Process APIs and Shell Escaping — Opening a terminal at a specific directory likely involves spawning a shell process with an escaped path; improper escaping can lead to injection vulnerabilities or broken paths with spaces.
• macOS Localization (.lproj directories) — The codebase supports 9 languages via .lproj/Localizable.strings files; adding a new language or updating strings requires understanding macOS's localization system and how to structure translations.
• Finder Pasteboard Access — The app likely reads the selected Finder item from the pasteboard or via Finder AppleScript events; understanding how Finder communicates the context is key to understanding how paths are extracted.
• URL Schemes and Custom App Protocols — Some terminal and editor apps support custom URL schemes for opening at a specific path; OpenInTerminal may use schemes like vscode://file/path or similar to open in editors.

• exa-org/exa — Alternative file browser with terminal integration; complementary tool for developers who want a modern ls alternative in the terminal.
• sharkdp/fd — Fast, user-friendly alternative to find; commonly used by OpenInTerminal users to search for files once in the terminal.
• lra/mackup — macOS app settings backup tool; useful for users who want to backup OpenInTerminal preferences and extend the app's configuration.
• golang/vscode-go — VS Code extension for Go; represents one of the many editors OpenInTerminal can open, showing the breadth of supported IDEs.
• microsoft/vscode — VS Code is the most popular editor integration target in OpenInTerminal; understanding VSCode's CLI (code command) is key to the integration.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow for building and testing Xcode projects

The repo currently uses .travis.yml (legacy CI), but lacks modern GitHub Actions. Building the OpenInTerminal-Lite and OpenInEditor-Lite Xcode projects (.xcodeproj files) in CI would catch build regressions early and verify the app builds successfully across different Swift/macOS SDK versions.

• [ ] Create .github/workflows/xcode-build.yml to build OpenInTerminal-Lite.xcodeproj and OpenInEditor-Lite.xcodeproj
• [ ] Configure the workflow to test on multiple macOS versions (e.g., 11, 12, 13)
• [ ] Add build artifact uploads for successful releases
• [ ] Update or replace .travis.yml with a deprecation notice pointing to the new GitHub Actions workflow

Create unit tests for Error.swift in both Lite variants

Both OpenInTerminal-Lite and OpenInEditor-Lite contain Error.swift files but there's no test coverage visible. Adding unit tests would verify error handling logic works correctly and prevent regressions when error types are modified.

• [ ] Create OpenInTerminal-Lite/OpenInTerminal-LiteTests/ErrorTests.swift with test cases for error cases defined in Error.swift
• [ ] Create OpenInEditor-Lite/OpenInEditor-LiteTests/ErrorTests.swift with equivalent test coverage
• [ ] Add test targets to the Xcode project files (.xcodeproj)
• [ ] Wire up tests into the CI workflow from the previous idea

Document terminal application support matrix and configuration in README

The README mentions support for Terminal, iTerm, Hyper, and Alacritty, but the file structure shows there are multiple Localizable.strings files (de, en, es, fr, it, ko, ru, tr, zh-Hans). The current README is incomplete (truncated at 'Support Terminal, [iTerm]...'). A comprehensive feature comparison table should document which terminal apps are supported in OpenInTerminal vs the Lite versions, and clarify localization support.

• [ ] Complete the truncated feature comparison table in README.md with all supported terminal applications for each variant
• [ ] Add a section documenting localization support (list all .lproj directories: de, en, es, fr, it, ko, ru, tr, zh-Hans)
• [ ] Document any configuration differences or limitations between full and Lite versions
• [ ] Mirror these updates to Resources/README-zh.md, Resources/README-tr.md, and Resources/README-de.md

• Add automated tests for the app detection logic in main.swift (none visible in file structure). Create a new Tests/ target and write unit tests for Launch Services calls and path resolution.
• Expand documentation for adding custom app support in Resources/README-Config.md. Analyze the code in main.swift and document the exact plist keys or Launch Services bundle IDs needed for new terminal/editor additions.
• Add GitHub Actions CI workflow to replace .travis.yml. Create .github/workflows/build.yml to compile both Lite and full variants and run any linting/tests on every PR.

The OpenInTerminal macOS application has a reasonable security posture for a Finder toolbar utility. No critical vulnerabilities were identified in the visible file structure. Primary concerns are configuration duplication and missing security disclosure procedures. The codebase appears to be a legitimate open-source project with proper version control setup. Recommendations focus on consolidating duplicate configurations, establishing clear security policies, and ensuring proper code signing/notarization for macOS distribution.

• Medium · Duplicate Entitlements Files — OpenInTerminal-Lite/OpenInTerminal-Lite/ and OpenInEditor-Lite/OpenInEditor-Lite/. Multiple entitlements files exist with similar names (e.g., OpenInTerminal-Lite.entitlements and OpenInTerminal_Lite.entitlements). This duplication could lead to inconsistent security configurations or confusion about which entitlements are actually applied during the build process. Fix: Consolidate duplicate entitlements files. Keep only one entitlements file per target and remove the redundant one. Update Xcode project settings to reference the single entitlements file.
• Low · No SECURITY.md Policy — Repository root. The repository lacks a SECURITY.md file to define vulnerability disclosure procedures. This makes it difficult for security researchers to responsibly report issues. Fix: Create a SECURITY.md file that outlines how to responsibly disclose security vulnerabilities (e.g., contact email, responsible disclosure timeline).
• Low · Missing Code Signing Configuration Documentation — OpenInTerminal.xcodeproj and related projects. As a macOS Finder toolbar app, the project requires proper code signing and notarization. No explicit documentation about code signing practices or build security is visible in the file structure. Fix: Document code signing and notarization procedures. Ensure builds are properly signed and notarized. Consider adding build security checks to CI/CD pipeline (.travis.yml).
• Low · Limited CI/CD Security Visibility — .travis.yml. The .travis.yml file is present but its contents are not provided for review. Travis CI configurations can contain security misconfigurations like exposed API keys or insecure build steps. Fix: Review .travis.yml for hardcoded secrets. Use environment variables for sensitive data. Enable branch protection and require CI to pass before merging.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.