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/thebaselab/codeapp 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 all four use cases

• Last commit 6w ago
• 3 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 91% 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 thebaselab/codeapp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/thebaselab/codeapp.

What it runs against: a local clone of thebaselab/codeapp — 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 thebaselab/codeapp | 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 ≤ 73 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "thebaselab/codeapp(\\.git)?\\b" \\
  && ok "origin remote is thebaselab/codeapp" \\
  || miss "origin remote is not thebaselab/codeapp (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 "Code.xcodeproj/project.pbxproj" \\
  && ok "Code.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: Code.xcodeproj/project.pbxproj"
test -f "CodeApp/Assets.xcassets/Contents.json" \\
  && ok "CodeApp/Assets.xcassets/Contents.json" \\
  || miss "missing critical file: CodeApp/Assets.xcassets/Contents.json"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"
test -f ".swift-format" \\
  && ok ".swift-format" \\
  || miss "missing critical file: .swift-format"
test -f "Code App.entitlements" \\
  && ok "Code App.entitlements" \\
  || miss "missing critical file: Code App.entitlements"

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

Code App is a full-featured code editor for iPad that brings VS Code-like functionality to iOS/iPadOS using a native Swift UI paired with monaco-editor for syntax highlighting and editing. It includes embedded runtimes for Python 3.9.2, Clang 14.0.0, PHP 8.3.2, Node.js 18.19.0, and OpenJDK 8, plus Git version control, terminal emulation (70+ commands), LSP support, SSH, and local web development capabilities—all running natively on iPad without requiring a remote server. Xcode monorepo structure: Code.xcodeproj is the primary project with three schemes (Code App main, CodeUI simulator variant, extension). Source lives in CodeApp/ with modular asset structure (Assets.xcassets for colors, Git indicators, accent themes). Native Swift dominates (975k LOC); small Objective-C/C++ bridges (11k LOC) handle system integration; monaco-editor and language runtimes are precompiled frameworks downloaded by downloadFrameworks.sh, not source-checked.

iPad developers and educators who need a serious code editor and runtime environment on their tablet, without tethering to a remote server or desktop. Includes developers working in Python, C/C++, PHP, JavaScript/Node, and Java who want to write, test, and deploy code directly on iPad.

Actively maintained and production-ready. The app is published on the App Store (ID 1512938504) with active CI/CD pipelines (.github/workflows contains build.yml, production.yml, test.yml) and regular feature additions (embedded runtimes, LSP support, SSH). Codebase is 975k+ lines of Swift, indicating substantial maturity, though the iPad platform is inherently niche.

Single-point-of-failure risk: maintenance depends heavily on thebaselab (primary org). Complex embedded runtime management (5 separate language distributions must be kept in sync across repos: cpython, llvm-project, php-src, nodejs-mobile, android-openjdk-build-multiarch). iPad SDK and App Store policy changes could break functionality; iOS/Swift is also a closed-source dependency chain. No visible npm package.json or robust dependency management shown—frameworks are downloaded via downloadFrameworks.sh shell script, which is opaque.

Recent work tracks Git integration (gutter indicators visible in Assets.xcassets/Git colorsets), language server protocol support (LSP for Python & Java marked ✅ in README), SSH support, and embedded terminal expansion. CI pipelines (build.yml, production.yml, test.yml) suggest regular release cycles. No visible recent commit dates in provided data, but the presence of three distinct GitHub Actions workflows indicates active deployment cadence.

git clone https://github.com/thebaselab/codeapp
cd codeapp
./downloadFrameworks.sh
open Code.xcodeproj

Then in Xcode: switch to CodeUI target for simulator testing, or Code App for device, then build (Cmd+B). Requires Xcode 13+ and macOS 11+.

Daily commands: No traditional dev server. Build and run on iPad simulator or device via Xcode:

xcodebuild -scheme 'Code App' -configuration Debug -destination 'platform=iOS Simulator,name=iPad Pro (12.9-inch)'

Or use Xcode GUI: Product → Run (Cmd+R). The app is self-contained; no backend required.

• Code.xcodeproj/project.pbxproj — Main Xcode project configuration; defines build targets, schemes, and all source file references for Code App, Code UI framework, and extension targets.
• CodeApp/Assets.xcassets/Contents.json — Root asset catalog configuration; declares all image sets, color sets, and icons used throughout the app for theming and UI rendering.
• .github/workflows/build.yml — CI/CD pipeline for automated builds; orchestrates compilation, testing, and deployment across the main and production branches.
• .swift-format — Swift code style configuration; enforces consistent formatting across the entire codebase for all contributors.
• Code App.entitlements — App capabilities and sandbox entitlements; grants permissions for file access, git operations, terminal, and SSH required on iPad.

Add a New Language Icon & Asset

1. Create a new SVG icon file named after the language (e.g., rust.svg) (CodeApp/Assets.xcassets/icons/rust.imageset/rust.svg)
2. Create imageset folder structure with Contents.json declaring the SVG (CodeApp/Assets.xcassets/icons/rust.imageset/Contents.json)
3. Update the asset catalog to include the new imageset (CodeApp/Assets.xcassets/icons/Contents.json)
4. Reference the asset in code via UIImage(named: "rust") or Image("rust") in SwiftUI

Add a New Theme Accent Color

1. Create a new colorset folder (e.g., CodeApp/Assets.xcassets/AccentColors/teal.colorset/) (CodeApp/Assets.xcassets/AccentColors/teal.colorset/Contents.json)
2. Define light and dark variant colors in the colorset JSON (CodeApp/Assets.xcassets/AccentColors/teal.colorset/Contents.json)
3. Update AccentColors/Contents.json to register the new colorset (CodeApp/Assets.xcassets/AccentColors/Contents.json)
4. Access via Color("teal") in SwiftUI theme picker code

Add a New Git Status Color

1. Create colorset in Git folder (e.g., git.renamed.colorset/) (CodeApp/Assets.xcassets/Git/git.renamed.colorset/Contents.json)
2. Define light/dark colors matching VS Code's git decorator palette (CodeApp/Assets.xcassets/Git/git.renamed.colorset/Contents.json)
3. Update Git/Contents.json to include the new status (CodeApp/Assets.xcassets/Git/Contents.json)
4. Reference in gutter indicator rendering code via Color("git.renamed")

Configure CI/CD Pipeline for New Target

1. Add new Xcode scheme in project settings (Code.xcodeproj/xcshareddata/xcschemes/NewTarget.xcscheme)
2. Update build.yml to add xcodebuild step for the new scheme (.github/workflows/build.yml)
3. Ensure new target obeys swift-format rules (.swift-format)
4. Update production.yml if the target should be released to App Store (.github/workflows/production.yml)

• Swift + SwiftUI — Native iPad framework for high-performance, responsive UI with deep OS integration (file access, process management, terminal).
• Monaco Editor (WebView) — Proven, feature-rich editor used by VS Code; provides syntax highlighting, IntelliSense, and multi-language support via web standards.
• Language Servers (LSP) — Decouples language intelligence from UI; enables Python, Java, and other LSP-compliant servers to run natively on iPad.
• Embedded Runtimes (Node, PHP, Python, Java, C/C++/WASM) — Allows full development workflows without server dependency; users can code, run, and debug entirely on device.
• Git Integration (native) — Core version control without external dependencies; enables clone, commit, diff, push/pull with SSH support for iPad workflows.

• Monaco Editor in WebView instead of native TextKit2

  • Why: Monaco provides better language support, VS Code parity, and rapid feature iteration; web rendering is acceptable on modern iPad hardware.
  • Consequence: Slight performance overhead vs. native text editing; requires careful memory management and WebView lifecycle handling.

• Embedded single-machine runtimes instead of cloud execution

  • Why: Offline-first, low-latency, privacy-preserving workflow matches iPad use case and App Store policies.
  • Consequence: Limited by device resources (CPU, memory, storage); not suitable for heavy compute or multi-machine orchestration.

• Sandbox confinement (App Store entitlements)

  • Why: Required by iOS/iPadOS App Store; enables secure distribution and user data protection.
  • Consequence: Restricted file access, no unrestricted network access, no custom kernel modules; developers must use provided capabilities.

• Not a remote SSH editor client for cloud VMs (bidirectional sync may be limited).
• Not a real-time collaborative editing platform (no built-in Operational Transformation or CRDT).
• Not a container/Docker runtime (uses single embedded processes, not containerized environments).
• Not a visual/drag-drop UI builder (code-first, text-centric workflow only).
• Not a full IDE debugger (basic runtime support; advanced debugging limited by sandbox).

1. downloadFrameworks.sh is a black box: builds external binaries; must run before Xcode opens, or linking will fail with 'framework not found'. 2. iPad simulator quirks: CodeUI target exists specifically because Code App target doesn't always work on simulator—always use CodeUI for simulator testing. 3. Entitlements required: Code App.entitlements defines critical sandbox capabilities; removing or altering them breaks file I/O and terminal functionality. 4. Framework binary management: Frameworks are pre-compiled blobs—cannot modify runtimes without rebuilding from holzschu/cpython, holzschu/llvm-project, etc., which are forks with custom patches. 5. No visible package manager config: No Podfile, no SPM Package.swift at root—all dependency management is manual or via downloadFrameworks.sh; risky for reproducibility. 6. App Store sandbox constraints: iOS sandbox may prevent certain operations that work on macOS; Git SSH, terminal commands, and file access are all subject to Apple's app review.

• Language Server Protocol (LSP) — Code App implements LSP for Python and Java to provide intelligent code completion, linting, and go-to-definition without reimplementing language-specific analysis; understanding LSP is essential to extending language support.
• WebAssembly (WASM) — Code App uses Clang 14.0.0 compiled to WebAssembly to run C/C++ code directly on iPad; WASM is critical to sandboxed runtime execution without native compilation bottlenecks.
• iOS/iPadOS Sandbox and Entitlements — Code App must operate within Apple's sandboxing constraints; entitlements (Code App.entitlements) define which file I/O, network, and terminal operations are permitted by the OS.
• Git Porcelain and Plumbing Commands — Code App implements clone, commit, push, pull, and diff operations; understanding Git's command hierarchy is essential to adding or debugging version control features.
• SwiftUI and State Management — Code App's entire UI is built in SwiftUI (975k LOC Swift); mastering @State, @ObservedObject, and view composition is mandatory for any UI contribution.
• Static Binary Linking and Framework Distribution — Code App bundles precompiled frameworks for Python, Clang, PHP, Node, and Java; understanding how downloadFrameworks.sh manages binary linking and framework path resolution is critical to runtime troubleshooting.
• Diff Algorithms and Unified Diff Format — Code App displays diffs in a diff editor (gutter indicators suggest line-by-line visualization); understanding how unified diff parsing and rendering works is needed to extend or fix diff features.

• microsoft/vscode — Direct design inspiration for Code App's UI and feature set (mentioned explicitly in README as design template).
• microsoft/monaco-editor — The embedded editor component powering Code App's syntax highlighting, autocomplete, and diff viewer.
• jashkenas/coffeescript — Example of a language toolchain compiled to JavaScript/WebAssembly; relevant to understanding Code App's Clang/C++ compilation strategy via WASM.
• evanw/esbuild — Alternative embedded dev environment (JavaScript bundler); shows parallel approach to providing local tooling without remote servers.
• twilio/flutter-webrtc — SSH terminal emulation over IP; relevant to Code App's SSH support feature and remote session management.

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 workflow for Swift code formatting validation

The repo contains a .swift-format configuration file but no CI workflow to enforce formatting standards. Given the Xcode project structure with multiple schemes (Code App, Code UI, extension), adding a GitHub Actions workflow to validate Swift formatting on PRs would catch style violations early and maintain code consistency across contributors.

• [ ] Create .github/workflows/swift-format.yml that runs on pull_request events
• [ ] Use swift-format CLI to check formatting against .swift-format config
• [ ] Fail the check if formatting violations are detected
• [ ] Add step to output violations in a format that GitHub can display as annotations
• [ ] Test against CodeApp/, Code.xcodeproj/ source files

Create comprehensive GitHub Actions workflow for multi-language runtime testing

The repo advertises support for multiple runtimes (Python, Java/OpenJDK, C/C++/WebAssembly, Node, PHP) but there's no visible CI workflow (test.yml exists but is not shown in the structure) validating that these runtimes function correctly. A matrix-based workflow testing code execution across these languages would catch regressions when runtime integration code changes.

• [ ] Expand or create .github/workflows/test.yml with matrix strategy for: Python, Java, C/C++/clang, Node.js, PHP
• [ ] Add sample scripts in a tests/runtimes/ directory for each language (e.g., tests/runtimes/python_test.py, tests/runtimes/java_test.java)
• [ ] Execute each test script via the appropriate runtime and validate output
• [ ] Add a status badge to README.md showing test results
• [ ] Reference the test results in contributing guidelines

Document and create unit tests for terminal command integration layer

The README mentions '70+ commands available' in the embedded terminal but there's no visible test coverage or documentation of the command interface. The lack of a tests/ or Tests/ directory suggests testing infrastructure is minimal. Creating unit tests for the terminal command parser/executor would improve reliability and serve as executable documentation for new contributors.

• [ ] Create CodeApp/Tests/TerminalCommandTests.swift file structure
• [ ] Identify the main terminal command handler/parser classes in CodeApp/
• [ ] Write unit tests covering: command parsing, common commands (cd, ls, git, npm, etc.), error handling, and piping
• [ ] Document the 70+ supported commands in CodeApp/TerminalCommands.md with examples
• [ ] Add test target to Code.xcodeproj and integrate into GitHub Actions CI

• Add unit tests for Git integration: The Assets.xcassets/Git colorsets exist for status indicators (added, deleted, modified, ignored), but no test coverage is visible for the Git diff/gutter rendering logic. Start by creating XCTest cases in CodeApp/Tests/ for GitDiffView or similar classes.
• Document the downloadFrameworks.sh build process: The shell script downloads and links 5 language runtimes but has no inline comments or supporting README explaining each URL, checksum, or version constraint. Add detailed comments and a FRAMEWORKS.md guide listing dependencies and their sources (cpython, llvm-project, php-src, nodejs-mobile, android-openjdk-build-multiarch).
• Implement missing theme accent color documentation: There are 8 accent color definitions in Assets.xcassets/AccentColors (blue, gray, green, orange, pink, purple, red, yellow) but no visible Settings view or documentation on how to switch themes. Create a ThemePickerView SwiftUI component and document theme selection in CODE.md or the wiki.

• High · Embedded Terminal with 70+ Commands - Potential Command Injection Risk — CodeApp - Terminal functionality (mentioned in README plan). The application provides an embedded terminal with 70+ available commands. This feature could be vulnerable to command injection attacks if user input is not properly sanitized before being passed to shell execution. Terminal input handling needs careful validation. Fix: Implement strict input validation and sanitization for all terminal commands. Use allowlisting for permitted commands. Avoid using shell=True or equivalent. Implement sandboxing where possible. Conduct security testing on command execution paths.
• High · Local Web Development Environment - Potential Network Exposure — CodeApp - Local web development environment (Node + PHP runtime). The app embeds Node.js and PHP runtime for local web development. These services could potentially be exposed to network access if not properly isolated, especially on iPad where network boundaries may be unclear. Fix: Ensure all embedded web services (Node, PHP) are bound only to localhost/127.0.0.1. Implement network sandboxing. Document security implications. Consider using App Transport Security (ATS) to restrict network access.
• High · C/C++ Runtime with WebAssembly and Clang - Code Execution Risk — CodeApp - C/C++ Runtime with WebAssembly (with clang). The application includes a C/C++ runtime with WebAssembly compilation capabilities (clang). This allows arbitrary code compilation and execution, which poses significant security risks if the compilation/execution environment is not properly sandboxed. Fix: Implement strict sandboxing for WebAssembly execution. Restrict access to system resources from compiled WASM. Implement resource limits (memory, CPU). Regular security audits of the WASM runtime. Consider code signing requirements.
• High · Missing Git SSH Implementation — CodeApp - Git version control functionality. The README plan lists 'SSH' as a future feature but does not show it as completed. Git operations may be using insecure authentication or may lack proper credential management for SSH keys. Fix: When implementing SSH support, use secure key storage (iOS Keychain). Implement proper host key verification. Avoid storing credentials in plaintext. Use SSH agent-like mechanisms for key management.
• Medium · Local Java Runtime (OpenJDK) - Potential Vulnerability Surface — CodeApp - Local Java (OpenJDK) runtime. The embedded OpenJDK runtime introduces a large attack surface. OpenJDK versions may contain known vulnerabilities. The sandboxing of Java execution context is unclear from the provided information. Fix: Keep OpenJDK regularly updated to patch versions. Implement strict sandboxing of Java execution. Monitor OpenJDK security advisories. Consider using a restricted Java execution environment or containers.
• Medium · Python Runtime - Potential Code Execution Risk — CodeApp - Built in Python runtime. The built-in Python runtime allows arbitrary Python script execution. Without proper sandboxing, this could access sensitive files or system resources. Fix: Implement filesystem restrictions for Python execution. Restrict access to sensitive APIs and system calls. Use restrictive sandboxing. Document security implications for users. Consider running Python in a restricted environment.
• Medium · Version Control System (Git) - Credential Storage Concerns — CodeApp - Git version control (clone, commits, diff, push, pull). The application implements Git clone, commits, push, and pull operations. Git credentials, tokens, and authentication data need secure storage and handling. Fix: Store Git credentials securely using iOS Keychain. Never store credentials in plaintext configuration files. Implement credential prompt mechanisms. Use SSH keys with secure storage. Clear credentials on app logout.
• Medium · Diff Editor - Potential XSS in Web-Based Display — CodeApp - Diff editor functionality. The diff editor likely renders code/diffs in a web view using Monaco Editor. If file content contains malicious code, it could be rendered without proper escaping. Fix: Ensure Monaco Editor properly escapes all user-generated content. Implement Content Security Policy (CSP) for any web views. Validate and sanitize file content before rendering.
• Low · Missing Dependency File Information — undefined. No Package.swift, Podfile, or other dependency manifests were provided Fix: undefined

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.