feat: auto-repair missing dependencies on start

[Brajesh2022]

Context & Motivation

Many users have been reporting execution failures during the final stage of the installation. Upon investigation, I discovered these failures were consistently caused by broken or missing Termux dependencies (such as glibc, proot, or ca-certificates).

In some cases, the dependencies were simply missing. In more stubborn cases, the installer (or Termux package manager) detected the dependency as "already installed" and skipped reinstalling it, even though the underlying libraries were corrupted. To solve this permanently, I added a multi-layered auto-repair system.

Changes Included

1. Initial Auto-Repair: If the standalone binary fails to execute, the script automatically triggers a pkg reinstall for the required packages (proot, glibc, ca-certificates). This forces Termux to repair corrupted libraries even if it thinks they are already installed.
2. Deep Update Fallback: If the first repair fails (which can happen if the local package cache is severely desynced), a secondary fallback is triggered. It performs a completely headless pkg upgrade (using --force-confdef --force-confold to avoid blocking user prompts) followed by another repair pass.
3. Legacy Conflict Resolution: The repair block actively removes old/conflicting binaries from ~/.local/bin and clears the shell cache (hash -r) so the system reliably executes the new installation in $PREFIX/bin.

Testing & Verification

I deliberately corrupted my own Termux environment to ensure the auto-repair functions precisely as intended.

• Missing Dependency Test: I verified that pkg reinstall correctly acts as an installation command if the package is entirely missing.
• Corrupted Dependency Test: I manually corrupted the crucial libc.so.6 library. The script successfully detected the resulting binary execution failure, initiated the repair sequence, and fully restored the corrupted library.
• Stubborn Failure Simulation: I created a wrapper around the pkg command to deliberately intercept and block the initial pkg reinstall, verifying that the script successfully detects the persisting failure, moves to the deep pkg upgrade fallback, and successfully repairs the binary on the second pass.

To test this fix locally, you can run:

curl -fsSL https://raw.githubusercontent.com/Brajesh2022/antigravity-cli-termux/fix-auto-repair/install.sh | bash

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a dependency repair fallback when the installed agy binary fails to execute, attempting to reinstall key packages and retrying the version check before failing.

Changes:

• Adds an automatic pkg reinstall step for proot, glibc, and ca-certificates when binary execution fails.
• Removes installed binaries and the ~/.local/agy directory before retrying.
• Re-runs the --version check and only dies if the retry also fails.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Brajesh2022]

@wallentx A quick heads up regarding the Copilot AI review on PR: please don't rely on it! Copilot hallucinates
I'd highly recommend using Google Gemini Code Assist GitHub Review instead! I've been using it and it's significantly better. It actually finds real bugs and understands full file context rather than producing hallucinations like this one.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[Brajesh2022]

@wallentx Can you please review this PR and merge it if everything looks good? Thanks 🙂

[Brajesh2022]

#9 (comment)

[wallentx]

Sorry for the delay, I've been in interviews and baby stuff. I'll get to this tonight

[wallentx]

Copilot Code Review is pretty crap, so I closed/reopened to trigger the Gemini Code Review.
Update: https://developers.google.com/gemini-code-assist/docs/deprecations/consumer-code-review
lol it is being shut down in a few weeks

[Brajesh2022]

@wallentx You can use "/gemini review" to trigger a review for a PR at any point in time.

For example, if new commits are pushed after the initial review, simply comment "/gemini review" again on the PR. Gemini will analyze the latest state of the pull request

[Brajesh2022]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces an automatic dependency repair and package upgrade sequence in install.sh when the installed binaries fail to execute. However, a critical issue was identified where this logic deletes active binaries in PRoot mode and incorrectly uses Termux-specific pkg commands in non-Termux environments. It is recommended to wrap the repair logic in an environment check to target only Termux environments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[Brajesh2022]

I think they'll either release AntiGravity Code Assist or something equally crazy... or maybe fully shut it down 😢

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

[Brajesh2022]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces Termux-specific dependency repair logic in install.sh to handle binary execution failures by attempting to reinstall key dependencies (proot, glibc, and ca-certificates) and updating packages. Feedback focuses on improving the robustness of the run_pkg_with_spinner function by passing variables to awk via -v and reusing GLIBC_PCT to prevent temporary file leaks on interruption. Additionally, it is recommended to use apt update instead of pkg upgrade to avoid an intrusive and slow full system upgrade when only updating package definitions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Intrusive Full System Upgrade vs. Updating Package Metadata

The message says "Upgrading package definitions...", but the command executed is pkg upgrade, which performs a full upgrade of all installed packages in the Termux environment. This can be extremely slow, consume significant bandwidth, and potentially introduce breaking changes to the user's other installed tools.

If the goal is only to update the package index/metadata (to resolve desynced package caches), you should use apt update instead. This is fast, safe, and non-intrusive.

Suggested change

	run_pkg_with_spinner "Upgrading package definitions..." pkg upgrade -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold"
	run_pkg_with_spinner "Updating package definitions..." apt update

[Brajesh2022]

replaced the full "pkg upgrade" step with a simple "apt update". It still refreshes package metadata, but avoids unexpected upgrades and keeps the installer faster and less intrusive for users.

Tested locally and everything is working well.

[wallentx]

I think Gemini might have off bu suggesting apt instead of pkg for a native Termux environment. https://wiki.termux.com/wiki/Package_Management#:~:text=We%20strongly%20recommend%20to%20use%20a%20pkg%20utility%20instead%20of%20apt%20directly.

[Brajesh2022]

yeah termux usually recommends using pkg instead of apt

The only reason I accepted Gemini suggestion and went with apt update here was that pkg upgrade ends up doing a full system upgrade. I was worried that if someone's installation is a bit outdated, the auto-repair path could suddenly spend 10+ minutes upgrading half their environment (Python, Node.js, etc) just to fix a glibc issue

With "lapt update, we can just refresh the package metadata and fix desync issues quickly without unexpectedly upgrading everything

What do you think? Should we switch back to pkg, or keep it as apt update here?

[wallentx]

Speaking generally on what this script does, my take is that this is useful functionality for someone who isn't familiar with Termux or the CLI, but for anyone who is, this might be seen as negative/unwanted behavior.

I think it is typically a bad practice to silently install things without at least prompting the user or letting them know what the script is doing. I think you expressed that same feeling with your concern about a full system upgrade.

I could also see scenarios where the user may be running their own compiled version of something like proot (or any other package) for some specific behavior, and the behavior of this could possibly replace that.

The spirit of what this is wanting to accomplish has good intentions, but I think there could be too many possible problems that a user might run into that the repair functionality assumes it can fix, such is the case with #9. I think that assumption might even mask the actual problem. #9 (comment) is actually an exact example of this masking the issue, and misdiagnosing the problem as being dependency related, and assuming that the problem can be fixed by following the guide.
I think that the scenario of "this doesn't work, and we can't fix it, and this is the real error that shows why it isn't working" is the useful output.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

[wallentx]

I suppressed copilot reviews on push since it was too noisy, and had too many false positives. Though I did see that GitHub does allow for different "Effort" levels now

[Brajesh2022]

That's a really good point, and I completely agree. I hadn't thought about the impact on power users with custom-compiled proot setups.

I also read through Issue #9 and now I see exactly what you mean. If someone's CPU throws an Illegal instruction (SIGILL) error, forcing them through a dependency reinstall is a pretty bad experience. It also hides the actual error message they need to see, like "FATAL ERROR: This binary was compiled with aes enabled".

What do you think about this approach instead?

1. Smart detection: if the engine fails with errors like "Illegal instruction" or "Exec format error" (similar to Issue [Bug] SIGILL / Illegal Instruction (rcpc feature missing) on Samsung Galaxy S10e #9), the script immediately stops, doesn't touch any packages, and prints the exact system error.

2. Explicit consent: if the error clearly points to missing libraries such as libc.so.6 or other shared objects, the script will ask the user first: "We detected a corrupted or missing Termux dependency. Would you like to attempt an automatic repair? [Y/n]"

This way we never silently modify a power user's setup without their permission, while also making sure hardware or CPU-related issues aren't masked by an automatic repair attempt.

What do you think?

[wallentx]

@Brajesh2022 given that we are now seeing reports like #10 (comment), I think the most important thing is that failures surface the original error message. The easiest way to ensure that is to decouple the install from the execution of agy.

If the installer replaces the real startup failure with "check dependencies" or runs repair logic first, the user loses the actual signal we need for troubleshooting. Since we do not control the upstream agy binary, startup failures may change from version to version: missing libraries, CPU instruction issues, loader problems, upstream crashes, or something else entirely. Trying to classify all of that in the installer feels fragile, and it risks masking the real problem.

I think a best-effort dependency check flow could still be useful, but it should be explicit: something like a -c / --check option that includes a clearly prompted repair step that tells the user it will attempt to reinstall proot, glibc, and ca-certificates dependencies if we detect that they are missing.

For the default install path, I think the script should stay minimal: install the binaries, verify the files exist, and avoid running agy --version as a gate. If agy fails when launched, it should fail with the original upstream/runtime error visible so we can diagnose the real cause.