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/CodeEditApp/CodeEdit 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.

GO — Healthy across the board

• Last commit 4w ago
• 22+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 51% of recent commits

_{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 CodeEditApp/CodeEdit repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/CodeEditApp/CodeEdit.

What it runs against: a local clone of CodeEditApp/CodeEdit — 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 CodeEditApp/CodeEdit | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 57 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of CodeEditApp/CodeEdit. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/CodeEditApp/CodeEdit.git
#   cd CodeEdit
#
# 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 CodeEditApp/CodeEdit and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "CodeEditApp/CodeEdit(\\.git)?\\b" \\
  && ok "origin remote is CodeEditApp/CodeEdit" \\
  || miss "origin remote is not CodeEditApp/CodeEdit (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "CodeEdit/AppDelegate.swift" \\
  && ok "CodeEdit/AppDelegate.swift" \\
  || miss "missing critical file: CodeEdit/AppDelegate.swift"
test -f "CodeEdit.xcodeproj/project.pbxproj" \\
  && ok "CodeEdit.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: CodeEdit.xcodeproj/project.pbxproj"
test -f ".swiftlint.yml" \\
  && ok ".swiftlint.yml" \\
  || miss "missing critical file: .swiftlint.yml"
test -f ".github/workflows/CI-pull-request.yml" \\
  && ok ".github/workflows/CI-pull-request.yml" \\
  || miss "missing critical file: .github/workflows/CI-pull-request.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 57 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~27d)"
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/CodeEditApp/CodeEdit"
  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).

CodeEdit is a native macOS code editor built entirely in Swift that provides syntax highlighting, code completion, project find-and-replace, integrated terminal, git integration, and extensibility via plugins. It solves the problem of macOS developers needing a lightweight, community-driven alternative to heavyweight editors like VS Code or JetBrains IDEs by offering native performance and macOS-first UX. Monolithic Xcode project (CodeEdit.xcodeproj/) with a single AppDelegate entry point. The structure shows a central CodeEdit/ directory containing the main app, Assets for UI resources, and .github/workflows/ automation for CI/CD, release management, and pre-release builds. Swift Package Manager integration visible in xcshareddata/swiftpm/Package.resolved.

macOS developers and engineers who want a modern, performant code editor built natively for Apple Silicon and Intel Macs, with particular appeal to open-source contributors and those seeking an alternative to Electron-based editors. Community contributors shaping a free, open-source editor.

Early-stage but actively developed: the project has 2M+ lines of Swift code, 32+ contributors, automated CI/CD workflows (.github/workflows/), and explicitly states in the README that it is 'not yet recommended for production use.' The presence of pre-release versions, release-drafter automation, and version bump CI pipelines shows active development momentum, but the honest disclaimer indicates core features are still stabilizing.

High risk for production use due to explicit pre-release status in the README. Single-language dependency (pure Swift, ~2M LOC) means the team is betting entirely on Swift and AppKit stability. No visible test file list in the top 60 structure (despite test automation workflows), suggesting incomplete test coverage. The repo's rapid feature expansion (terminal, debugging, git integration) means breaking changes are likely.

Active development on release automation: .github/workflows/ includes CI-bump-build-number.yml, release-drafter.yml, and appcast.xml management for Sparkle-based auto-updates. The AppCast/ directory with Jekyll config (_config.yml, Gemfile) and release notes infrastructure suggests ongoing work on distribution and update delivery. The .swiftlint.yml presence indicates code quality enforcement is being tightened.

git clone https://github.com/CodeEditApp/CodeEdit.git
cd CodeEdit
open CodeEdit.xcodeproj
# Then build & run via Xcode's Play button (Cmd+R)

No traditional npm/pod install needed; Xcode and Swift Package Manager handle dependencies via Package.resolved.

Daily commands: Open CodeEdit.xcodeproj in Xcode and press Cmd+R, or from Terminal: xcodebuild -scheme CodeEdit -configuration Debug followed by running the .app bundle. The CI workflows (.github/workflows/CI-*.yml) reveal the canonical build: swift build or Xcode's native build system.

• CodeEdit/AppDelegate.swift — Application entry point and lifecycle management for the macOS app; essential for understanding how the editor initializes and handles system events.
• CodeEdit.xcodeproj/project.pbxproj — Xcode project configuration defining all build targets, schemes, and dependencies; required for setting up the development environment.
• .swiftlint.yml — Code style and linting rules that all contributors must follow; enforces consistency across the Swift codebase.
• .github/workflows/CI-pull-request.yml — Primary CI/CD pipeline for pull requests; defines automated testing, linting, and validation that every contribution must pass.
• CONTRIBUTING.md — Contributor guidelines and workflow expectations; mandatory reading for anyone planning to submit code.
• .github/ISSUE_TEMPLATE/bug_report.yml — Issue reporting structure that helps triage bugs and features; shapes how the community communicates problems.

• AppDelegate (SwiftUI, AppKit NSApplicationDelegate) — Handles macOS app lifecycle: launch, shutdown, window management, menu bar, system event routing
  • Failure mode: App fails to launch or crashes on quit; menu bar interactions broken; window state not restored
• Build System (Xcode) (xcodebuild, Xcode project configuration) — Compiles source, links frameworks, bundles resources, signs app, manages scheme variants
  • Failure mode: Build fails; signing fails; wrong icon bundle included; dependencies not resolved
• CI/CD Pipeline (GitHub Actions, SwiftLint, xcodebuild) — Validates every PR: compiles, lints, runs tests; blocks merge on failures; produces release artifacts
  • Failure mode: Bad code merged; releases contain bugs; linting not enforced; no rollback capability

Add a new build scheme variant

1. Create a new icon asset set following the naming pattern (e.g., AppIconAlpha for alpha builds) (CodeEdit/Assets.xcassets/AppIconAlpha.appiconset/Contents.json)
2. Register the new icon set in the Xcode project by editing the project configuration (CodeEdit.xcodeproj/project.pbxproj)
3. Create a new build scheme if needed or update existing scheme settings to use the new icon variant (CodeEdit.xcodeproj/xcshareddata/xcschemes/CodeEdit.xcscheme)

Add a new CI/CD check for pull requests

1. Define the new validation logic as a workflow job in the PR pipeline (.github/workflows/CI-pull-request.yml)
2. If the check involves Swift code quality, update SwiftLint rules to match the validation (.swiftlint.yml)
3. Document the new requirement in the contributing guide so contributors understand expectations (CONTRIBUTING.md)

Update release and update distribution process

1. Modify the release notes generation workflow to capture new metadata or format (.github/workflows/CI-release-notes.yml)
2. Update the Sparkle appcast XML to reflect new release information structure (AppCast/appcast.xml)
3. Re-run the appcast generation workflow to publish the updated feed (.github/workflows/appcast.yml)

• Swift + SwiftUI — Native macOS-first framework provides best integration with system APIs, native performance, and Xcode IDE support; team chose to be 'unapologetically macOS'
• Xcode + xcodeproj — Direct control over build configuration, scheme variants for dev/beta/release, and tight integration with Xcode debugger for IDE development
• Sparkle framework (inferred from appcast) — Standard macOS software update framework for secure, automatic app updates without forcing App Store distribution
• GitHub Actions CI/CD — Native integration with repository, no external CI vendor lock-in, cost-effective for open-source projects
• SwiftLint — Enforces consistent Swift code style across distributed contributor base without manual review overhead

• macOS-only, no iOS/Linux/Windows support

  • Why: Deep integration with macOS APIs, simplified UI/UX targeting single platform, focused developer effort
  • Consequence: Excludes potential users on other platforms; cannot cross-compile easily

• Multiple app icon variants (dev/beta/release/pre)

  • Why: Allows developers and testers to run multiple build configurations simultaneously without confusion
  • Consequence: Increased asset maintenance burden; 4 separate icon sets to maintain and update

• Open-source community-driven model with contribution guidelines

  • Why: Transparency, community trust, and distributed developer effort; aligns with 'by the community, for the community' mission
  • Consequence: Higher review/merge overhead; coordination complexity; quality variability from contributors

• SwiftPM + Xcode project instead of pure SwiftPM package

  • Why: Full control over build settings, resource bundles, and signing for a shipping macOS app
  • Consequence: Less modular; harder to split into independent packages; mixed dependency resolution (SwiftPM + Xcode)

• Cross-platform support (explicitly macOS only)
• App Store distribution (uses Sparkle for direct updates instead)
• Cloud-based or web-based editing (native desktop app only)
• Real-time collaborative editing (no multi-user synchronization visible in structure)
• Proprietary/closed-source (explicitly open-source forever)

No visible Tests/ folder in the top 60 files despite CI workflows (tests.yml, test_app.sh) — tests may live inline or in a subdirectory not surfaced here; check with maintainers. OpenWithCodeEdit scheme visible in xcschemes but not explained — a Finder context-menu integration that requires separate app target configuration. Sparkle framework is implicitly required (appcast.xml references) but not visible in Package.resolved — likely a binary dependency or CocoaPods integration. macOS version floor not specified in visible files — check project.pbxproj for MACOSX_DEPLOYMENT_TARGET. No environment variables visible in CI workflows yet, but pre-release and release workflows are separate — understand token / signing certificate requirements before attempting a release build.

• AppKit (Cocoa) — CodeEdit is built on macOS's native UI framework (AppDelegate, NSWindow); without AppKit knowledge you cannot modify windows, menus, or system integration
• Sparkle Framework (Auto-Updates) — The appcast.xml and release automation depend on Sparkle; understanding how it validates and downloads updates is essential for the release pipeline
• Swift Package Manager (SPM) — CodeEdit uses SPM for dependency resolution (visible in Package.resolved); you must understand how to add/remove packages without breaking the Xcode project
• macOS Sandbox & Entitlements — Any feature accessing files, shell commands, or system services requires entitlements in the .entitlements file (not visible here but required); missing entitlements silently fail
• Code Signing & Notarization — The CI workflows (CI-pre-release.yml) handle signing and notarization; understand certificate provisioning and entitlements or pre-release builds will fail cryptographically
• SwiftLint Static Analysis — .swiftlint.yml enforces code style automatically in CI; PRs that violate rules will fail the lint workflow even if they build
• GitHub Actions for macOS CI/CD — Multiple .github/workflows/*.yml files define how the app is built, tested, and released; understanding GitHub Actions is required to modify the release process

• microsoft/vscode — Direct competitor in the macOS code editor space; VS Code's Electron architecture is the problem CodeEdit aims to solve with native Swift
• MacEdit/MacEditApp — Another native macOS editor attempt; understand why CodeEdit chose AppKit+SwiftUI approach vs. their architecture
• jhawthorn/fzy — Fast fuzzy finder used by many editors; CodeEdit's 'find and replace' feature likely leverages or reimplements similar algorithms
• jesseduffield/lazygit — Terminal-based git UI showing the git integration patterns that CodeEdit integrates as a native feature
• apple/swift — CodeEdit's entire codebase is Swift; understanding Swift language and stdlib evolution directly impacts maintainability

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 macOS App Icon Validation & Generation Tests

The repo contains multiple app icon sets (AppIcon.appiconset and AppIconAlpha.appiconset) with specific size requirements (16, 32, 128, 256, 512px at 1x and 2x). There's no CI workflow validating that all required icon sizes exist, are properly named, or meet Apple's guidelines. A new contributor could add a GitHub Action workflow that validates icon dimensions and completeness before release.

• [ ] Create .github/workflows/validate-app-icons.yml workflow
• [ ] Write shell script in .github/scripts/validate_app_icons.sh to check all required icon sizes exist in CodeEdit/Assets.xcassets/AppIcon*.appiconset/
• [ ] Validate icon file dimensions match expected sizes (16, 32, 128, 256, 512) using ImageMagick or sips
• [ ] Add step to catch missing or incorrectly-sized icons before release builds

Add Unit Tests for AppDelegate Initialization & Lifecycle

CodeEdit/AppDelegate.swift exists but there's no corresponding test file visible in the structure. Given this is a macOS app with complex windowing, preferences, and menu handling, AppDelegate tests are critical. A new contributor could create comprehensive tests for app launch, window management, and event handling.

• [ ] Create CodeEditTests/AppDelegateTests.swift (assuming Tests directory exists in project)
• [ ] Add tests for app startup initialization and default window creation
• [ ] Add tests for open-with-CodeEdit functionality (referenced in OpenWithCodeEdit.xcscheme)
• [ ] Add tests for application(_:openFile:) and other file-opening delegate methods

Implement Linting CI Check for Xcode Project File Consistency

The repo has .swiftlint.yml for Swift code linting, but CodeEdit.xcodeproj/project.pbxproj is a binary/complex file that frequently causes merge conflicts and inconsistencies. A new contributor could add a CI workflow that validates the Xcode project structure using xcodeproj validation or custom Ruby/Python scripts to catch misconfigured build phases or missing file references.

• [ ] Create .github/workflows/validate-xcode-project.yml workflow
• [ ] Write validation script in .github/scripts/validate_xcode_project.sh to check project.pbxproj integrity
• [ ] Validate all Swift source files referenced in the file structure are properly added to build targets
• [ ] Check for duplicate UUIDs or orphaned build phases that commonly cause CI failures

• Add comprehensive unit tests for AppDelegate.swift lifecycle methods (application(:didFinishLaunchingWithOptions:), applicationDidBecomeActive(:), etc.) — the CI has test infrastructure but no visible test files for the app entry point.: Medium: Core stability; low risk of introducing new bugs
• Document the architecture of the 'OpenWithCodeEdit' Finder integration scheme visible in .xcschemes — add a ARCHITECTURE.md or file a PR explaining how the secondary app target works and why it exists.: Low: Onboarding friction; no contributor currently understands this without digging into xcodeproj
• Create a DEVELOPMENT.md guide with exact macOS/Xcode version requirements, instructions to build both CodeEdit and OpenWithCodeEdit targets, and how to test the Sparkle auto-update cycle locally using appcast_pre.xml.: Low: Directly unblocks new contributors; current README focuses on features, not developer setup

CodeEdit is a macOS code editor with a reasonable security posture based on available information. No critical vulnerabilities were identified from the file structure alone. Primary concerns include: (1) Swift Package Manager dependency management needs continuous monitoring, (2) CI/CD workflows require auditing for proper secret and permission handling, (3) Appcast XML processing should be hardened against XXE attacks, (4) Full source code analysis is needed to evaluate for insecure API usage, sandbox violations, and IPC security. The project follows good practices with open-source transparency and GitHub-based CI/CD, but should implement automated dependency scanning and regular security audits.

• Medium · Appcast Configuration Exposure — AppCast/. The AppCast directory contains appcast.xml and appcast_pre.xml files with Jekyll configuration (_config.yml) and Ruby plugins. These files are used for app update distribution and may contain sensitive information or be subject to injection attacks if not properly validated. Fix: Ensure appcast XML files are properly validated against XXE (XML External Entity) attacks. Implement strict XML parsing with external entity resolution disabled. Review _config.yml for any exposed sensitive data.
• Medium · GitHub Workflow Security Concerns — .github/workflows/. Multiple CI/CD workflows are present (.github/workflows/) including release, pre-release, and bump build number workflows. These workflows may have permission escalation risks or insecure secret handling patterns. Fix: Audit all workflow files for: (1) least privilege permissions, (2) proper secret masking, (3) restricted branch protection, (4) validation of third-party actions. Ensure secrets are not logged or exposed in workflow output.
• Medium · Dependency Resolution File Checked In — CodeEdit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved. Package.resolved file is present in version control (CodeEdit.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved). This locks dependency versions and may contain outdated or vulnerable packages. Fix: Regularly audit and update Swift Package Manager dependencies. Implement automated dependency scanning using tools like Dependabot or Swift Security advisories. Review Package.resolved for known vulnerable versions.
• Low · Incomplete File Structure Analysis — CodeEdit/ (source files), CodeEdit.xcodeproj/project.pbxproj. The full content of Swift source files (.swift), Xcode project configuration (project.pbxproj), and dependency manifest files (Package.swift) were not provided for analysis. Fix: Perform deep code review of: (1) Swift source files for insecure APIs, (2) AppDelegate.swift for sandbox violations, (3) IPC/XPC communication security, (4) File handling and path traversal risks, (5) Cryptographic implementations, (6) Build settings in pbxproj for security flags.
• Low · Missing Security Headers in Jekyll Config — AppCast/_config.yml. AppCast uses Jekyll configuration for web-based app update information. Web security headers may not be configured in _config.yml. Fix: If AppCast is deployed as a website, ensure: (1) HTTPS is enforced, (2) Security headers (CSP, X-Frame-Options, etc.) are set, (3) XML is validated server-side, (4) CORS policies are properly configured.

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.