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/prasmussen/gdrive 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.

WAIT — Stale — last commit 3y ago

• 16 active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 81% of recent commits
• ⚠ No test directory detected

_{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 prasmussen/gdrive repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/prasmussen/gdrive.

What it runs against: a local clone of prasmussen/gdrive — 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 prasmussen/gdrive | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1144 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "prasmussen/gdrive(\\.git)?\\b" \\
  && ok "origin remote is prasmussen/gdrive" \\
  || miss "origin remote is not prasmussen/gdrive (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "gdrive.go" \\
  && ok "gdrive.go" \\
  || miss "missing critical file: gdrive.go"
test -f "cli/parser.go" \\
  && ok "cli/parser.go" \\
  || miss "missing critical file: cli/parser.go"
test -f "drive/drive.go" \\
  && ok "drive/drive.go" \\
  || miss "missing critical file: drive/drive.go"
test -f "auth/oauth.go" \\
  && ok "auth/oauth.go" \\
  || miss "missing critical file: auth/oauth.go"
test -f "handlers_drive.go" \\
  && ok "handlers_drive.go" \\
  || miss "missing critical file: handlers_drive.go"

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

gdrive is a command-line interface for Google Drive that allows users to upload, download, list, delete, and sync files directly from the terminal without a GUI. Written in Go, it provides OAuth2-based authentication and supports both interactive user flows and service account authentication for automation, with features like bi-directional syncing (via appProperty tags), revision management, and .gdriveignore pattern matching. Monolithic structure with three core layers: (1) auth/ handles OAuth2 flows and token persistence, (2) drive/ contains business logic for all Drive API operations (list.go, upload.go, sync.go, etc.), (3) cli/ wraps the drive layer with command parsing, flags, and handler dispatch. Main entry point is gdrive.go; handlers_drive.go and handlers_meta.go route CLI commands to drive operations.

Systems administrators, DevOps engineers, and power users who manage Google Drive files programmatically or via shell scripts; CI/CD pipelines that need headless Google Drive access; users managing multiple Drive accounts who need CLI-based file orchestration rather than web UI.

Abandoned — the README explicitly states 'This repository is not maintained anymore' and directs users to gdrive3 (glotlabs/gdrive). No recent commits visible in the provided data, though the codebase is stable and production-ready for existing users. This is a legacy project superseded by an actively maintained v3.

High risk for new projects: this repo is unmaintained and explicitly deprecated. Single maintainer (prasmussen) with no visible activity. Dependency pinning via Godeps (Go 1.5 era) means vendored code is frozen and won't receive security updates. OAuth2 integrations with Google APIs may break if Google deprecates v2 or v3 APIs. Start new projects with gdrive3 instead.

Nothing — the project is unmaintained. The only visible workflow is .github/workflows/release.yaml for building binaries. No active development, PRs, or issues visible in the file structure. Users are directed to gdrive3 (glotlabs/gdrive) as the successor.

go get github.com/prasmussen/gdrive
# Binary will be at $GOPATH/bin/gdrive
# OR on macOS: brew install gdrive
# First run: gdrive about (will prompt for OAuth verification code)

Daily commands: No dev server — this is a CLI binary. After go get or brew install, run: gdrive about (first time, prompts for auth), then gdrive list, gdrive upload <file>, gdrive download <id>, gdrive sync upload/download <localdir> <driveid>. Use --config flag or GDRIVE_CONFIG_DIR env var to manage multiple Drive accounts.

• gdrive.go — Main entry point and CLI dispatcher; every contributor must understand how commands are routed to handlers
• cli/parser.go — Core CLI argument parsing and command registration; defines how all subcommands are structured
• drive/drive.go — Primary Google Drive API client wrapper; the abstraction layer between CLI and Google Drive API
• auth/oauth.go — OAuth2 authentication flow; critical for understanding token management and initial setup
• handlers_drive.go — Command handlers for drive operations; bridges CLI context to drive package functionality
• drive/sync.go — Sync engine orchestration; contains the most complex multi-file synchronization logic
• util.go — Shared utility functions across CLI and drive packages; referenced throughout codebase

Add a new drive operation command

1. Implement the operation logic in drive/[operation].go (e.g., drive/rename.go) (drive/rename.go)
2. Create a handler function in handlers_drive.go following the existing pattern (e.g., handleRename) (handlers_drive.go)
3. Register the command in cli/parser.go by adding a new CommandHandler entry in the init or factory function (cli/parser.go)
4. Test the flow: the new command will be automatically discoverable via gdrive [operation] --help (gdrive.go)

Add a new authentication method

1. Implement the auth backend in auth/ directory (e.g., auth/service_account.go) (auth/oauth.go)
2. Update auth/file_source.go to handle new credential format if necessary (auth/file_source.go)
3. Modify drive/drive.go NewDriveService() to accept and use the new auth method (drive/drive.go)
4. Update handlers_meta.go or cli/context.go to expose auth config options (cli/context.go)

Extend sync logic with custom change detection

1. Add detection logic in drive/sync_list.go to identify custom change patterns (drive/sync_list.go)
2. Implement change handler in drive/sync.go within the main sync loop (drive/sync.go)
3. Add corresponding sync_upload.go or sync_download.go logic if directional handling is needed (drive/sync_upload.go)
4. Update compare.go to handle new comparison rules if needed (compare.go)

Add a new export/import format

1. Extend drive/export.go with format-specific export logic and MIME type mappings (drive/export.go)
2. Extend drive/import.go with format-specific import handling (drive/import.go)
3. Register format flags in cli/flags.go for the export/import commands (cli/flags.go)
4. Update handlers_drive.go to pass format parameters through the command pipeline (handlers_drive.go)

• Go 1.5+ — Statically-linked binaries for easy distribution; fast compile; built-in concurrency for sync operations
• Google API Go Client (vendor/google.golang.org/api/drive/v3) — Official Google Drive API bindings; handles protocol buffers and API versioning automatically
• oauth2 (vendor/golang.org/x/oauth2) — Standard library for OAuth2 token management and refresh; integrates with Google's auth endpoints
• go-git-ignore (vendor/github.com/sabhiram/go-git-ignore) — Gitignore pattern matching for sync exclude lists; familiar syntax for users
• graph library (vendor/github.com/soniakeys/graph) — Graph algorithms for resolving file hierarchies and path traversal in sync operations

• Vendored dependencies instead of go modules

  • Why: This is a legacy Go project predating go.mod ubiquity; uses Godeps for reproducible builds
  • Consequence: Larger repo size; requires manual vendor updates; tooling assumes GOPATH

• Sync implementation uses in-memory state structures instead of persistent DB

  • Why: Simplicity; avoids external dependencies; suitable for CLI use case
  • Consequence: Large syncs may consume significant memory; no crash recovery within a sync session

• Token storage in plaintext files (~/.gdrive/token.json)

  • Why: User convenience; no external secrets manager dependency
  • Consequence: High security risk if ~/.gdrive is world-readable; no encryption at rest

• Single-threaded file operations with optional --parallel flag

  • Why: Avoids rate-limiting and API quota exhaustion; predictable behavior
  • Consequence: Slower throughput for bulk operations compared to async frameworks

• Real-time file watching and bi-directional sync (sync is one-shot, not daemon-based)
• Support for Google Shared Drives or Team Drives (API focus is personal My Drive)
• Encryption or local caching layer (all operations are direct to Google Drive)
• Cross-platform GUI (CLI-only tool)

OAuth2 token must be stored in ~/.gdrive/token.json (or custom GDRIVE_CONFIG_DIR); first run blocks interactively to fetch it. Service account JSON path is relative to config dir, not absolute. Sync relies on appProperty 'gdrive-id' to track files — files uploaded manually or via upload command in a sync dir will be ignored. Godeps vendoring is outdated (Go 1.5 era); no go.mod, so dependency updates require manual Godeps/Godeps.json edits. Timeout handling in drive/timeout_reader.go may cause stalls on slow connections.

• OAuth2 Authorization Code Flow — gdrive uses this to authenticate users interactively; auth/oauth.go implements token caching and refresh cycles
• Google Drive appProperty (custom metadata) — Sync state is tracked via appProperty 'gdrive-id' on remote files; essential to understand how sync avoids re-uploading files
• Streaming downloads with timeout handling — drive/timeout_reader.go wraps HTTP responses to interrupt stalled downloads; prevents CLI hangs on slow/unreliable connections
• Gitignore pattern matching (glob rules) — .gdriveignore files exclude files from sync using the same rules as .gitignore; vendor/sabhiram/go-git-ignore implements this
• Service account authentication (JWT bearer flow) — Allows headless server-to-server Drive access without user interaction; alternative to OAuth2 interactive flow
• Recursive file traversal with breadth-first search — drive/path.go resolves paths by walking Drive hierarchy; sync operations must traverse entire directories efficiently
• Command-line flag parsing and context passing — cli/parser.go, cli/flags.go, and cli/context.go implement custom flag handling; understanding the flag→context→handler flow is key to adding new commands

• glotlabs/gdrive — Official successor (gdrive3) — actively maintained, rewritten for modern Go, recommended for new projects
• rclone/rclone — Cloud storage sync tool supporting Google Drive and 50+ backends; more featureful alternative for multi-cloud sync
• odeke-em/drive — Another Google Drive CLI in Go with similar feature set (upload/download/sync); abandoned but shows alternative design patterns
• google/google-api-go-client — Underlying Google Drive API client library used by gdrive; understanding its structs is essential for modifications
• golang/oauth2 — OAuth2 library used in auth/oauth.go; needed to understand token refresh and flow setup

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 unit tests for auth package (auth/oauth.go, auth/file_source.go)

The auth package handles sensitive OAuth token management and file operations but has no visible test coverage. This is critical for a tool that manages Google Drive access credentials. Testing token refresh, file persistence, and error handling would prevent regressions in authentication flow.

• [ ] Create auth/oauth_test.go with tests for token refresh, validation, and expiration handling
• [ ] Create auth/file_source_test.go with tests for token file read/write operations and permission checks
• [ ] Test error scenarios: invalid token files, missing credentials, network failures
• [ ] Add test fixtures for mock OAuth responses in auth/testdata/

Add integration tests for sync operations (drive/sync.go, drive/sync_download.go, drive/sync_upload.go)

The sync functionality is complex with three separate files handling different sync directions (download/upload). No tests are evident, yet sync is prone to data loss bugs (e.g., file conflicts, partial transfers). Integration tests would catch regressions in file state management.

• [ ] Create drive/sync_test.go with mock Google Drive API responses
• [ ] Test sync_download.go: verify correct file selection, conflict detection, and resumable downloads
• [ ] Test sync_upload.go: verify local file detection, large file chunking, and error recovery
• [ ] Test drive/sync.go: verify two-way sync doesn't create duplicates or lose metadata

Add GitHub Action workflow for cross-platform binary releases (extending .github/workflows/release.yaml)

The repo currently has a release.yaml workflow but the file structure shows _release/build-all.sh exists, suggesting manual cross-platform builds. The release workflow should be enhanced to automatically build binaries for linux/amd64, linux/arm64, darwin/amd64, darwin/arm64, and windows using Go's built-in cross-compilation, matching the current manual process in _release/build-all.sh.

• [ ] Update .github/workflows/release.yaml to build all target architectures (read _release/build-all.sh to understand current targets)
• [ ] Add matrix strategy for OS/ARCH combinations (linux/darwin/windows × amd64/arm64/386)
• [ ] Integrate _release/upload.sh logic into the workflow to upload built binaries to release
• [ ] Add checksums generation and signature steps for security

• Add unit tests for drive/path.go path resolution and parent ID traversal — currently no test files visible in the structure, making refactoring risky.
• Document service account setup in README — the note about 'JSON file obtained through Google API Console' is vague; add a worked example with scopes required for sync/upload/download.
• Add integration tests for drive/sync_upload.go and drive/sync_download.go — sync is noted as 'slow and uses a lot of memory' but there are no benchmarks or regression tests to catch performance regressions.

The gdrive codebase presents significant security concerns due to its unmaintained status, outdated Go version support, and insecure token storage practices. The project uses old vendored dependencies without modern vulnerability tracking. Critical issues include plain

• High · Unmaintained Project with Outdated Dependencies — Repository root, vendor/ directory. The repository is explicitly marked as not maintained. The codebase uses vendored dependencies from golang.org/x/net and other packages that may contain known vulnerabilities. No security patches or updates are being applied. Fix: Migrate to gdrive 3 (https://github.com/glotlabs/gdrive) which is actively maintained. If continuing with this version, audit and update all vendored dependencies for known CVEs.
• High · Insecure Token Storage — auth/file_source.go, auth/oauth.go. The README indicates that OAuth tokens are stored in a plaintext file in the .gdrive folder in the home directory. The documentation explicitly states 'anyone with access to this file will also have access to your google drive', indicating the token file lacks proper encryption or access controls. Fix: Implement encrypted token storage using system keyring/credential managers. Restrict file permissions to 0600 (owner read/write only). Consider using OAuth token refresh mechanisms with shorter expiration times.
• High · Outdated Go Version Support — README.md, build configuration. The project targets Go 1.5 or higher, which is extremely outdated (released 2015). Go 1.5 has numerous known security vulnerabilities that have been patched in modern versions. Fix: Update minimum Go version requirement to at least Go 1.19 or higher (preferably 1.21+). Rebuild binaries with modern Go toolchain.
• Medium · Potential OAuth Code Injection Risk — auth/oauth.go. The authentication flow in auth/oauth.go requires user interaction with verification codes. While the README mentions following a printed URL for authentication, there's potential for man-in-the-middle or local injection attacks if the OAuth flow implementation doesn't properly validate redirect URIs or state parameters. Fix: Review OAuth implementation to ensure: (1) State parameter validation is implemented, (2) Redirect URI validation is strict, (3) PKCE is used for additional security, (4) Secure random number generation for tokens.
• Medium · Vendored Dependencies Not Tracked for Vulnerabilities — vendor/ directory, Godeps/Godeps.json. The codebase uses vendored dependencies without a modern dependency management system visible (no go.mod in provided structure). This makes it difficult to track and update vulnerable dependencies. The vendor directory includes old versions of golang.org/x/net which may have known CVEs. Fix: Migrate from Godeps to Go Modules (go.mod/go.sum). Regularly scan dependencies using 'go list -json ./...' with vulnerability scanners like govulncheck. Set up automated dependency updates.
• Medium · Potential Path Traversal in File Operations — drive/path.go, drive/sync.go, drive/download.go, drive/upload.go. The drive package includes path handling (drive/path.go) and file operations (download, upload, sync). Without reviewing the actual implementation, path traversal vulnerabilities are a common risk in file synchronization tools. Fix: Implement strict path validation using filepath.Clean() and restrict operations to intended directories. Use filepath.Join() safely and validate that resolved paths stay within allowed directories.
• Low · Missing Security Release Information — Repository root. No SECURITY.md file or security policy documented in the repository. No information on how to report security vulnerabilities responsibly. Fix: Create a SECURITY.md file with responsible disclosure guidelines. Even though unmaintained, provide instructions for reporting security issues.
• Low · Deprecated Context Package Usage — vendor/golang.org/x/net/context/. The codebase uses vendored golang.org/x/net/context which was deprecated and moved into the standard library (context package) in Go 1.7+. Fix: Replace vendored context package with standard library 'context' package. Update imports throughout the codebase.

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.