software-dev | Chris Titus Tech

GitHub Copilot App Is Actually Good... Just Not with Copilot

Mon, 17 Aug 2026 00:00:00 GMT

GitHub Copilot is a terrible name for this app. Microsoft has put the Copilot name on everything, but this is much more useful as a GitHub desktop dashboard for Linux, macOS, and Windows.

I use it to organize repositories, issues, pull requests, and notifications. I do not use the built-in Copilot subscription. Instead, I connect the app to my existing Codex subscription through CLIProxyAPI.

The GitHub App I Actually Wanted

The app's My work view puts review requests, issues, pull requests, and repository activity in one place. That matters when your notification feed is constantly moving and older projects are easy to forget.

My normal workflow looks like this:

Open My work and scan new activity across every connected repository.
Open an issue or pull request in the app to get the context.
Ask for a plan or initial scaffolding when an issue needs code.
Continue the detailed implementation in my preferred editor or terminal.
Review, close, or archive the item when the work is done.

I do not want the app to replace my IDE. It is the front door to the work: a fast way to decide what needs attention before I move into Codex, HerdR, or another development environment.

Prioritize Issues Across Every Repository

The biggest win is triage. GitHub's normal notification stream tells you what happened, but it does not necessarily tell you what matters most.

I can ask the app to prioritize my outstanding issues and pull requests. If several users report the same WinUtil problem, that cluster should rank above a one-off request with little impact. A useful prompt is:

Prioritize my outstanding issues and pull requests across all connected
repositories. Group duplicate or closely related reports, rank them by user
impact and urgency, and explain why each item deserves its position.

The result is a practical queue instead of an endless inbox.

AI can miss context, so I still review the source issue before acting. The ranking is a starting point, not an automatic decision-maker.

Add and Synchronize Existing Repositories

Adding a large collection of repositories one at a time is tedious. I pointed the app at my working directory and asked it to identify local GitHub projects that were not already configured.

Once the repositories are available, the app can help spot stale clones, dirty worktrees, and branches that need attention. That is useful when I commit on one machine and later discover that another workstation has not pulled the change.

Never ask an agent to discard or overwrite local changes automatically. Have it report the repository state first, then review each proposed pull, commit, or cleanup action.

Replace the Copilot Provider with Codex

The app supports additional model providers. I use that capability to avoid buying another AI subscription for another application.

The path is:

GitHub Copilot app -> CLIProxyAPI on localhost -> OpenAI Codex

CLIProxyAPI is a third-party open-source project that signs in to supported AI services and exposes an OpenAI-compatible local endpoint. If your ChatGPT plan includes Codex, it can route the app through that existing access instead of a separately billed OpenAI Platform API key.

This is not an official GitHub or OpenAI integration. Review the project before installing it, keep it updated, and expect your normal subscription limits and terms to apply.

Install CLIProxyAPI on Linux

The CLIProxyAPI documentation recommends a community-maintained Linux installer. Download it first so you can inspect it before running it:

installer="$(mktemp)"
curl -fsSL \
  https://raw.githubusercontent.com/router-for-me/cliproxyapi-installer/refs/heads/master/cliproxyapi-installer \
  -o "$installer" || { rm -f "$installer"; exit 1; }

less "$installer"
bash "$installer"
rm -f "$installer"

The installer normally places the binary and configuration under ~/cliproxyapi/. It also creates a cliproxyapi.service user unit and generates a local API key.

Open ~/cliproxyapi/config.yaml and verify that the service is bound only to localhost:

host: "127.0.0.1"
port: 8317
auth-dir: "~/.cli-proxy-api"

api-keys:
  - "sk-replace-this-with-a-long-random-local-key"

Edit the existing values instead of replacing the entire configuration. If the installer already generated a strong local key, keep it. Protect the configuration with:

install -d -m 700 "$HOME/.cli-proxy-api"
chmod 700 "$HOME/cliproxyapi" "$HOME/.cli-proxy-api"
chmod 600 "$HOME/cliproxyapi/config.yaml"

Sign In to Codex and Start the Service

Run the one-time OAuth login as your normal desktop user:

cd "$HOME/cliproxyapi"
./cli-proxy-api --codex-login

For a headless machine, use the device-code flow instead of the browser callback:

./cli-proxy-api --codex-device-login

After signing in, restrict the saved OAuth credentials to your user:

find "$HOME/.cli-proxy-api" -type d -exec chmod 700 {} +
find "$HOME/.cli-proxy-api" -type f -exec chmod 600 {} +

Then enable the user service:

systemctl --user daemon-reload
systemctl --user enable --now cliproxyapi.service
systemctl --user status cliproxyapi.service

A desktop user service starts when you log in, which is normally all this setup needs.

Test the Local Endpoint

Before changing the GitHub app, confirm that the proxy is running and that its local key works:

read -rsp 'CLIProxyAPI key: ' CLIPROXY_API_KEY
printf '\n'
curl -fsS \
  -H "Authorization: Bearer ${CLIPROXY_API_KEY}" \
  http://127.0.0.1:8317/v1/models
unset CLIPROXY_API_KEY

A JSON model list confirms that the service is reachable, the key matches, and the Codex login was loaded.

Connect the GitHub Copilot App

In the GitHub Copilot app:

Open Settings.
Select Model providers.
Choose Add provider, then OpenAI.
Set the base URL to http://127.0.0.1:8317/v1.
Paste the local key from config.yaml.
Save the provider and select one of the Codex models it exposes.

Start with a disposable repository and a small test prompt. Confirm the diff and commands before trusting the setup with important work.

Troubleshooting

Check the service and recent logs with:

systemctl --user status cliproxyapi.service
journalctl --user -u cliproxyapi.service -n 100 --no-pager

If the app cannot connect, verify that the base URL includes /v1, the port is 8317, and the service is listening on 127.0.0.1.

For a 401 response, make sure the key entered in the app exactly matches a value under api-keys in config.yaml. After changing the configuration, restart the service:

systemctl --user restart cliproxyapi.service

If no Codex models appear, repeat the OAuth login and test /v1/models from the terminal before changing more app settings.

Faster GitHub Actions with Blacksmith

The video also shows Blacksmith, the sponsor for this walkthrough. Replacing the standard GitHub-hosted runners and enabling Blacksmith's cache cut one WinOnOneShot workflow from roughly five minutes to about two minutes in my test.

That result is from one project, not a promise for every workflow, but it is worth testing if CI wait time is slowing down your development loop.

Final Thoughts

The GitHub Copilot app is useful once I stop treating it as Copilot. It gives me one dashboard for repository activity, issue triage, pull requests, and local projects across Linux, macOS, and Windows.

Routing its AI features through CLIProxyAPI lets me use the Codex subscription I already have, while the app remains valuable even without AI as a GitHub organization and notification tool. For developers managing dozens of repositories, that organization is the real feature.

Sources

Video Walkthrough

The video shows my complete workflow, from replacing the built-in AI provider to triaging issues across roughly 100 repositories.

Watch the video directly on YouTube if the embed does not load.

I Rebuilt My Website in Astro - Was It Worth It?

Mon, 17 Aug 2026 00:00:00 GMT

Four years ago, I built this website with Hugo. In August 2026, I deleted the Hugo build, replaced it with Astro, and moved the entire production site without changing the URLs people already use.

Hugo was not broken. That is what made this migration interesting. The site had simply grown from a blog into a publication, video archive, search engine, download hub, newsletter funnel, and a pile of old links that absolutely could not disappear. Rebuilding the easy 80 percent would have taken an afternoon. Preserving the last 20 percent was the real project.

So, was moving from Hugo to Astro worth it? Yes, but not for the reason most framework comparisons give you.

Why Replace Something That Already Worked?

My original website setup was intentionally simple:

Markdown -> Hugo -> GitHub -> Cloudflare Pages

That workflow served me well for years. Hugo is fast, dependable, and still one of the best static site generators available. If you have a documentation site or a straightforward blog, I am not going to tell you to rewrite it because a JavaScript framework has a shinier home page.

But christitus.com stopped being a straightforward blog.

It now has hundreds of articles, category and tag archives, livestreams with synchronized chat replays, local search, downloads, newsletter signup, feeds, comments, ads, analytics, old redirects, and years of Markdown written against Hugo behavior. The Hugo version worked, but every custom feature added another template, partial, shortcode, SCSS rule, or vendor script to a stack that was getting harder to reason about as one system.

I wanted three things:

A frontend I could understand from the page down to the browser behavior.
Tests that proved the old links and content still worked.
A foundation that was easier to change without dragging a client framework into every page.

Astro fit that job. It gives me components and TypeScript at build time, ships static HTML by default, and lets browser JavaScript stay small and local. There is no React application hiding underneath this site. It is still a static website deployed by Cloudflare Pages.

The new publishing path is almost boring:

Markdown -> Astro -> GitHub -> Cloudflare Pages

The generator changed. The static-site philosophy did not.

The Website Was the Contract

The biggest mistake in any rebuild is treating the source code as the product. It is not. The product is everything people and machines can already reach.

Before changing the build, I captured Hugo's production output as a baseline. That clean build contained:

2,156 generated files
813 Hugo pages
125 paginator pages
244 aliases

That included much more than article HTML. It included case-sensitive URLs, category pages, tag pages, RSS feeds, sitemap entries, social metadata, search records, redirects, images, downloads, and weird historical edge cases nobody remembers until Google lands on one.

One tracked image even had to remain byte-for-byte identical at its old public path. Some old posts had empty categories. Others used historical capitalization that new articles are no longer allowed to use. The archive contained Hugo shortcodes, raw HTML, date-only front matter, timestamps with offsets, and posts where an omitted draft field meant published.

That mess is not bad data. It is a public compatibility contract accumulated over years.

Instead of cleaning up the archive and hoping for the best, the migration taught Astro how to read it. New content gets stricter rules. Old published content keeps working.

Rebuilding Hugo Behavior Without Hugo

Astro content collections now load the existing Markdown with typed metadata. The production build excludes drafts and future posts, but a separate local preview command lets me see them while writing. A repository-owned post scaffolder replaced Hugo archetypes and catches URL collisions before it writes a file.

The compatibility renderer handles the Hugo shortcodes that are actually in the archive, including YouTube, notices, tables, X posts, and Shopify embeds. An unknown active shortcode fails the build instead of quietly publishing broken template syntax. Literal shortcode examples inside code blocks remain article content.

This is the unglamorous part of a successful migration. I did not run a giant search-and-replace across old articles. I built a boundary around the history.

Routes received the same treatment. The Astro build generates and checks the homepage, posts, pagination, taxonomies, search index, feeds, sitemap, livestreams, player pages, legal pages, and redirects. The validator rejects collisions between content, static assets, redirects, feeds, and generated routes.

By the end, the new production artifact had a deterministic 1,183-route compatibility contract and 312 searchable entries. That matters more to me than whether one generator won a synthetic build-speed contest.

I Used the Migration to Delete Frontend Baggage

The Hugo site had grown a traditional frontend layer over time: Bootstrap, Font Awesome bundles, Fuse, Mark.js, Shuffle, theme scripts, Shopify code, SCSS partials, and many custom layout files.

The Astro conversion removed that layer and replaced it with:

reusable Astro components
one custom CSS token system
vanilla TypeScript for interactive behavior
self-hosted fonts
static pages with progressive enhancement

The result supports dark and light themes, keyboard navigation, local search, livestream browsing, synchronized chat, lazy comments, lazy ads, and an intent-driven store integration. The important part is that a visitor does not download a full client UI framework just to read an article.

Third-party code also stopped being a requirement for the page to function. Search uses a generated local index. The download page retains a direct store link if Shopify is blocked. The livestream player works without chat. Ads, comments, video APIs, and newsletter extras load only when they are needed.

That is the web I want: the content works first, and the integrations enhance it afterward.

Performance Was a Gate, Not a Vibe

Framework marketing loves a perfect Lighthouse screenshot. Real performance work is less glamorous.

The migration added a pinned mobile Lighthouse profile that runs three times on the homepage, an article, a category page, and the livestream archive. During the final review, those pages scored between 99 and 100 for performance, 100 for accessibility, 100 for SEO, and 96 for best practices in the local fallback environment. Median Largest Contentful Paint ranged from 1.58 to 1.95 seconds, with zero layout shift on those runs.

Those results did not appear automatically because the project used Astro. The commit history shows the real work:

stabilize Lighthouse performance
stabilize mobile listing performance
reduce webfont render delay
inline the site stylesheet
fix the remaining migration review findings

And after launch, I still changed the layout spacing, added missing support paths to search and downloads, adjusted the Lighthouse threshold to account for real run-to-run variance, and fixed the article table of contents so it actually stays pinned while scrolling.

That last part is important. A green migration does not mean the design is done. It means the new foundation is safe enough to improve.

The Test Suite Became the Real Feature

The final Astro build is checked by much more than npm run build.

The repository validates formatting, Markdown, dependency policy, Astro types, unit tests, deterministic output, the route contract, and the production build. Playwright then exercises the site in Chromium, Firefox, mobile Chromium, and WebKit. Browser tests cover the homepage, articles, taxonomy pages, search, downloads, newsletter signup, livestreams, chat and no-chat player states, redirects, the theme switcher, mobile navigation, keyboard access, and the 404 page.

Accessibility checks found a real contrast failure during development. It was fixed before the final run. That is exactly what I want from automation: not a badge, but a specific problem found before users have to report it.

The full clean validation produced a deterministic 1,285-page Astro build, ran 61 unit and workflow tests, exercised 66 applicable browser tests, and completed 12 Lighthouse runs. WebKit ran in its supported Playwright container because the fallback binary did not match my Fedora host libraries.

This is more ceremony than a personal blog needs. It is not more ceremony than a production publication with years of inbound links needs.

The Hidden Migration Was GitHub Automation

The visible redesign was only half the job.

Livestream and chat data had been updated by separate scheduled workflows that pushed generated data. The migration consolidated that pipeline and added guards around the exact commit being tested. Candidate automation changes are limited to the generated data paths, checks attach to the exact validated SHA, and interruption handling can reconcile the branch and pull request instead of blindly starting over.

Nobody watching the video will look at the homepage and say, "Nice immutable commit validation." That is fine. Infrastructure is successful when it makes the boring failures boring to recover from.

The same rule applied to deployment. The old Hugo output, Cloudflare settings, redirect behavior, and repository state were captured before cutover. A rewrite without a rollback plan is not confidence. It is gambling with extra steps.

What the Commit History Actually Shows

The main pull request contained 23 commits before it was merged. The sequence is more useful than the final screenshot:

write the specification and roadmap
  -> close planning and cutover gaps
  -> capture the Hugo baseline
  -> build the Astro content foundation
  -> build the editorial experience
  -> finish infrastructure and automation
  -> review, fix, measure, and repeat

The merged change touched 175 files, added 49,426 lines, and removed 7,408. A large part of those additions is recorded baseline and lockfile data, not 49,000 lines of shiny new application code. The deletions are more revealing: Hugo configuration, templates, archetypes, old pipeline assets, vendor scripts, and SCSS all left the production path.

The project did not begin with npm install astro. It began with nine planning and review commits that defined what could not break. Only then did the history move through baseline capture, content, design, infrastructure, performance, and final review.

That order is why this worked.

What Got Better

The obvious improvement is maintainability. A page is now composed from Astro components instead of behavior being spread across Hugo templates, partials, shortcodes, and global vendor scripts. TypeScript catches mistakes earlier, and the browser code lives beside the feature that needs it.

The editorial workflow is also safer. A new post command creates consistent front matter, uses the correct date and URL shape, requires a valid category, defaults to a draft, and refuses to overwrite or collide with an existing route.

Most importantly, I can make changes with evidence. If I touch search, routes, metadata, a feed, or the article layout, the repository has a focused way to prove whether I broke it.

What Astro Did Not Magically Fix

Astro did not make historical content clean. We had to model the exceptions. It did not make third-party integrations reliable. We had to build fallbacks. It did not guarantee accessibility or speed. We had to test both. It did not make deployment safe. We had to capture the old state and design a rollback.

It also moved the toolchain from one Hugo binary to Node, npm, a lockfile, Astro, TypeScript, Vitest, Playwright, Lighthouse, and supporting packages. That is a real dependency cost. The new stack is easier for me to extend, but it is not smaller in every possible sense.

If your Hugo site is fast, easy to maintain, and does everything you need, keep it. Rewrites are expensive. A framework switch without a concrete maintenance problem is just a new way to own the same website.

Was It Worth It?

For this site, yes.

Not because Astro defeated Hugo. Hugo did its job for years, and it gave us the stable static foundation that made a careful migration possible.

The move was worth it because the website now matches how I build software: plain-text content, static output, small client-side code, explicit contracts, repeatable tests, independent review, and a rollback when reality ignores the plan.

The final lesson is not "use Astro." It is this:

Never start a website rewrite by asking how to rebuild the homepage. Start by asking what the old website is already promising.

Capture those promises. Turn them into tests. Then change the engine.

That is how I replaced Hugo without replacing the website.