GitHub-Ops

Development biography · earlier archive

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

Biography

GitHub-Ops started on 2 October 2026, while the owner was setting up a GitHub Enterprise Cloud trial and a new organisation, entertrainmentuk, to hold the studio's company repositories. Doing that by hand meant jumping between GitHub's web settings, the gh command line, git config and the Copilot apps. It was also easy to lose track of which local folders were actually backed up. The repo's README records the machine setup, token scopes and account state for that day. The tool grew out of the same work: whenever a check was done by hand, it was written down as code.

The result is bin/ghops, a single Python 3 script that uses only the standard library. A short instructions file in the repo sets the rules for any AI agent working on it. No third-party dependencies are allowed. All GitHub access goes through the gh CLI, so the tool never reads or prints a token. Anything that changes GitHub must sit behind an explicit --apply flag and show a dry run otherwise. Account names and policy baselines live in config/ghops.json, not in the code. Every check prints the same one-line format (a tick, warning or cross, then a label and a detail), and longer findings go to dated Markdown reports.

The most distinctive idea is how cautious it is. Most commands only read. The few that write show exactly what they would do first. The last commit (2026-10-03) changed two things. API mutations are now judged by whether GitHub returned an error, not by what the response body contains. And the clean-up command now fails closed: if it can't get a reliable list of open files from lsof, it deletes nothing.

Who it is for. For the owner first: one developer with a personal account, one enterprise org and a large number of local projects spread across Documents, Downloads, Desktop and developer folders. Because the account names are in config, anyone with a similar setup could reuse it. Nothing shows anyone else has.

What it does. There are eight subcommands:

• doctor checks the gh version and login, token scopes against a required list (and prints the exact gh auth refresh fix), the git credential helper, git identity and commit signing. It then checks the Copilot CLI, the GitHub Copilot desktop app and whether it is signed in (it reads the app's latest log, and only the most recent auth event counts), the Copilot entitlement, and whether the user has a seat in the org.
• org audits the enterprise and organisation: plan, 2FA requirement, default permissions, members without 2FA, teams, Copilot billing and policy settings, seat activity, Actions permissions, rulesets and code-security configurations. It writes a dated report.
• local walks the configured folders up to a depth limit, skipping build and dependency folders, and lists every git checkout. It flags checkouts with no remote at all (not backed up anywhere), uncommitted changes, unpushed commits or no upstream branch.
• remote lists every repo on the user account and the org, cross-references them with the local scan, and finds local folders with no remote that share a name with a GitHub repo, which are likely disconnected copies of the same project.
• baseline compares the org's settings with the baseline in config. With --apply it enforces it: a free supply-chain configuration (dependency graph, Dependabot alerts and security updates) for private repos, and GitHub's recommended configuration for public repos, where secret scanning and code scanning are free.
• copilot seat-add / seat-remove assigns or removes Copilot Business seats, dry run by default.
• transfer moves named personal repos, or all private non-fork ones, into the org and repoints local origin remotes.
• cleanup finds abandoned tmp_pack_* files left by interrupted git fetches. It only counts files older than a day and skips any that lsof shows are still open.

A typical session. The owner runs bin/ghops doctor to confirm the machine is signed in with the right scopes. Next comes bin/ghops local, which shows, say, which project folders have never been pushed anywhere. Then bin/ghops remote shows which GitHub repos have no local clone, and which local folders look like disconnected copies. For any project worth keeping, the README suggests a gh repo create … --push command. Before changing the org, bin/ghops baseline prints the differences, and only --apply makes them.

What it isn't. It isn't a hosted service, a GUI, or a general-purpose GitHub manager. It has no tests and no release. It is a personal operations notebook that runs.

Features: what a visitor could see or try

There is nothing a visitor can try; it needs the studio’s credentials.

Technical foundations

• Language: Python 3, standard library only (argparse, json, subprocess, pathlib, re, shutil, datetime). A __pycache__/ghops.cpython-314.pyc file suggests it has been run on Python 3.14; this is inferred from a retained artifact.
• GitHub access: api() wraps gh api with an explicit API-version header, --paginate --slurp and JSON bodies on stdin. graphql() wraps gh api graphql. Token scopes are read from the X-Oauth-Scopes response header.
• Config: config/ghops.json holds the user, org, required scopes, scan folders, maximum depth, skipped folders, org baseline and the code-security baseline.
• Local packages: none. It doesn't import any of the studio's own packages.
• Integrations documented in the README (not part of the tool's code): the the project archive config, which wires the Copilot CLI and app to Xcode's xcrun mcpbridge and the semanticcompute, mac-resilience, md-tags, global-memory and ccx MCP servers, plus sourcekit-lsp and pyright.

Maturity by feature

Times from .git/logs/HEAD (Unix timestamps 1790949291–1791018429, +0100); all fall on 2026-10-02 and 2026-10-03.

The README's own status block says "Complete · Improvable, 80%", self-assessed on 2026-10-02.

Limitations, roadmap, FAQs

Limitations

• Built for one user and one org; macOS-specific checks (/Applications/GitHub Copilot.app, defaults, the project archive).
• No tests or CI; no packaging.
• doctor relies on the undocumented copilot_internal/user endpoint and on the Copilot app's log format, so either can break without warning.
• remote matches disconnected copies by folder name only, which is a guess, as the report says.
• There's a reports/documents-junk-2026-10-03.md file that no current subcommand produces. It probably came from a separate one-off session.

Roadmap : back up repos that have no remote, reconnect disconnected checkouts, move company repos into the org, turn on SSH commit signing, require 2FA in the org. The pending Copilot Business activation (payment method, then seat, then CLI policy) is account admin, not product roadmap. Keep it internal.

FAQs

• Does it change anything on its own? No. Every command that writes to GitHub or disk prints a dry run unless you pass --apply.
• Does it handle my GitHub token? No. It calls the gh CLI, which keeps the credential; the tool never reads or prints it.
• What do I need to install? Python 3 and the gh CLI, signed in. There are no pip packages.
• Can I point it at my own account? Yes: edit config/ghops.json (user, org, scan folders, baselines). It hasn't been tested outside the author's setup.
• Why are the reports not in the repo? They list private repository names and local paths, so reports/ is git-ignored.