amg
A command-line tool to manage and resume Codex sessions by git branch name.
Description
amg helps you quickly resume Codex sessions by matching them to git branch names. It searches through Codex session files (JSONL format) and finds the first session that matches your current or specified git branch, then resumes it with the appropriate configuration.
Installation
Using cargo-binstall (Recommended - Fastest)
Install pre-built binaries without compiling from source:
# Install cargo-binstall first (one-time setup)
# Install amg
This method downloads pre-built binaries from GitHub Releases, making installation much faster than compiling from source. Binaries are available for:
- Linux (x86_64)
- macOS (Intel and Apple Silicon)
- Windows (x86_64)
Using Makefile
This installs the binary to $HOME/.cargo/bin (default Cargo installation directory). Ensure $HOME/.cargo/bin is in your PATH (typically done automatically by rustup).
For a custom installation directory:
Using Cargo
From Source (Build Only)
The binary will be available at target/release/amg.
Usage
Basic Usage
Resume a Codex session for a specific branch:
Or use the shorter aliases:
Environment Variables
You can set environment variables to avoid passing flags every time:
# Optional, defaults to $HOME/.codex
Then simply run:
Options
--repo <REPO>: Repository path to grant Codex sandbox access to (required, or setCODEX_REPO)--codexdir <DIR>: Codex directory containing JSONL sessions (optional, defaults to$HOME/.codex, or setCODEX_CODEXDIR)-n, --dry-run: Print the command that would be executed without running it--no-tmux: Disable automatic tmux window creation (if$TMUXis set)
Examples
# Resume session for 'main' branch
# Dry run to see what command would be executed
# Resume without tmux (run inline)
# Use environment variables
How It Works
- Searches through the Codex directory (default:
$HOME/.codex) for JSONL session files - Reads the first line of each JSONL file to extract git branch information
- Matches sessions where
.payload.git.branchequals your specified branch name - Resumes the first matching session with appropriate sandbox configuration
Development
Prerequisites
- Rust 1.91 or later
- Cargo
Building
Running Tests
# Using cargo test
# Using nextest (faster, parallel)
# Or use the Makefile
Code Quality
The project uses strict linting and formatting:
# Run all CI checks
# Format code
# Run clippy
# Check formatting
Project Structure
src/
├── bin/
│ └── amg.rs # Binary entry point
├── cli/
│ ├── mod.rs # Main CLI logic
│ ├── args.rs # CLI argument parsing
│ ├── codex_cmd.rs # Codex command building
│ ├── scan.rs # Session scanning
│ ├── process.rs # Process execution
│ ├── util.rs # Utility functions
│ ├── constants.rs # Constants
│ ├── logging.rs # Logging setup
│ └── prelude.rs # Common imports
└── lib.rs # Library root
Releases
This project uses release-plz for automated releases. The release process is fully automated through GitHub Actions.
How Releases Work
-
Release PR Creation: When commits are pushed to
main, release-plz automatically creates or updates a release Pull Request with:- Version bumps in
Cargo.toml(based on Conventional Commits) - Updated
CHANGELOG.md(generated from git history) - Updated
Cargo.lock(if dependencies changed)
- Version bumps in
-
Release PR Review: Maintainers review the release PR to ensure:
- Version bumps are correct (semver based on commit types)
- Changelog accurately reflects changes
- All CI checks pass
-
Publishing: When the release PR is merged, release-plz automatically:
- Creates a git tag (format:
amg-v<version>, e.g.,amg-v0.1.0) - Publishes the crate to crates.io
- Creates a GitHub release with changelog
- Creates a git tag (format:
Version Bumping
Versions follow Semantic Versioning and are determined by commit types:
- Major version (
1.0.0→2.0.0): Breaking changes (detected bycargo-semver-checksor commits withBREAKING CHANGE:) - Minor version (
1.0.0→1.1.0): New features (feat:commits) - Patch version (
1.0.0→1.0.1): Bug fixes (fix:commits)
For Contributors
Important: All commits must follow the Conventional Commits specification for automatic versioning to work correctly.
Commit format: type(scope): description
feat(cli): add new command→ minor version bumpfix(scan): resolve session matching bug→ patch version bumprefactor(util): improve error handling→ no version bump (unless breaking)docs: update README→ no version bumpchore(deps): update dependencies→ no version bump
See .cursor/rules/commits/RULE.md for detailed commit guidelines.
Manual Release (if needed)
If you need to trigger a release manually or test locally:
# Install release-plz
# Update versions and changelog (creates release PR locally)
# Publish to crates.io (after merging release PR)
Secure Token Management with Bitwarden
For local development, you can use Bitwarden CLI to securely manage tokens required by release-plz.
Note: This repository intentionally does not integrate Bitwarden into GitHub Actions. CI releases use GitHub-native auth (the workflow
GITHUB_TOKENplus token-based authentication for crates.io publishing).
Quick Start
# One-time setup
# Run release-pr with tokens from Bitwarden
# Run release with tokens from Bitwarden
Setup
-
Install Bitwarden CLI:
# See docs/BITWARDEN_SETUP.md for other platforms -
Run setup script:
-
Create vault items in Bitwarden:
amg-release-github-token: Store your GitHub Personal Access Tokenamg-release-cargo-token(optional): Store your crates.io token
Usage
Recommended Workflow:
-
Unlock Bitwarden and export session (do this once per terminal session):
-
Run release commands:
Alternative: Interactive Unlock
If you haven't exported BW_SESSION, the script will prompt for your password:
Using scripts directly:
Customizing vault item names:
For Automation / Non-Interactive (Discouraged):
Avoid BW_PASSWORD (it puts your Bitwarden master password in an environment variable). Prefer unlocking once interactively and exporting BW_SESSION:
If you must automate login, use API keys:
For detailed setup instructions and troubleshooting, see docs/BITWARDEN_SETUP.md.
Contributing
Contributions are welcome! Please ensure:
- All tests pass:
make ci - Code is formatted:
make fmt - No clippy warnings:
make lint - Follow Conventional Commits - This is required for automatic versioning and changelog generation
Commit Message Format
Use the format: type(scope): description
Types:
feat: New feature (causes minor version bump)fix: Bug fix (causes patch version bump)refactor: Code refactoring (no version bump unless breaking)test: Adding or updating tests (no version bump)docs: Documentation changes (no version bump)style: Code style changes (no version bump)chore: Maintenance tasks (no version bump)
Examples:
feat(cli): add shorthand flag for repo argumentfix(scan): resolve session matching bugdocs: update installation instructions
See .cursor/rules/commits/RULE.md for detailed guidelines.
License
Licensed under either of:
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Author
Cardosaum