Skip to content

Conversation

@neubig
Copy link
Contributor

@neubig neubig commented Jun 16, 2025

  • This change is worth documenting at https://docs.all-hands.dev/
  • Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

End-user friendly description of the problem this fixes or functionality this introduces.

Fixes an issue where bash commands would timeout immediately on first run due to git clone operations hanging while waiting for user credentials.


Summarize what the PR does, explaining any non-trivial design decisions.

This PR addresses a critical issue where the system would hang when trying to clone organization-level microagent repositories that don't exist or require authentication. There were two main problems:

  1. The git token was not being passed to most runtimes, so it was not available when the org repo was cloned.
  2. If the token was not passed in or the repo didn't exist, cloning would wait for the terminal to enter a password, causing things to time out.

With these changes, code that previously timed out no longer does, so this is confirmed to work locally.

Screenshot 2025-06-15 at 8 09 25 PM

Link of any specific issues this addresses:

Fixes #9147

@neubig can click here to continue refining the PR


To run this PR locally, use the following command:

docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:5ad1026-nikolaik   --name openhands-app-5ad1026   docker.all-hands.dev/all-hands-ai/openhands:5ad1026

- Add GIT_TERMINAL_PROMPT=0 to prevent git from prompting for credentials
- Fix URL formatting in _get_authenticated_git_url to preserve domain
- Add tests for _get_authenticated_git_url method

This resolves the issue where bash commands would timeout immediately
when the system tried to clone non-existent org-level microagent repos
and git would hang waiting for user input.

Fixes #9147
- Add GIT_TERMINAL_PROMPT=0 to prevent git from prompting for credentials
- This resolves the issue where bash commands would timeout immediately
  when the system tried to clone non-existent org-level microagent repos
  and git would hang waiting for user input

The existing _get_authenticated_git_url method was working correctly.
The issue was specifically with the new org-level microagent cloning
feature not handling non-interactive git operations properly.

Fixes #9147
@neubig neubig force-pushed the fix/bash-timeout-interactive-git-clone branch from c2d2ca8 to dfe5f25 Compare June 16, 2025 00:26
- Update self.git_provider_tokens in clone_or_init_repo to ensure
  microagent loading uses the same tokens as main repository cloning
- This resolves the issue where org-level microagent repos were cloned
  without authentication, causing git to prompt for credentials
- Keep GIT_TERMINAL_PROMPT=0 as additional safety measure

The root cause was that get_microagents_from_org_or_user() was using
self.git_provider_tokens (set during initialization) instead of the
current tokens passed to clone_or_init_repo().

Fixes #9147
@neubig
Copy link
Contributor Author

neubig commented Jun 16, 2025

@OpenHands
self.git_provider_tokens = git_provider_tokens in the clone repo function is an antipattern because it is a function with unexpected side effects. Instead, find out why the runtime git provider tokens are not set at the time that this function is called for repo microagents.

@openhands-ai
Copy link

openhands-ai bot commented Jun 16, 2025

I'm on it! neubig can track my progress at all-hands.dev

- Remove antipattern from clone_or_init_repo function in base.py
- Update all runtime implementations to accept git_provider_tokens parameter:
  - DockerRuntime: Accept git_provider_tokens, remove user_id (Docker doesn't need it)
  - LocalRuntime: Accept both user_id and git_provider_tokens
  - E2BRuntime: Upgrade to inherit from ActionExecutionClient for consistency
  - ModalRuntime: Accept user_id and git_provider_tokens
  - DaytonaRuntime: Accept user_id and git_provider_tokens
  - RunloopRuntime: Accept user_id and git_provider_tokens
- Update AgentSession._create_runtime() to pass git_provider_tokens to all runtime types
- All runtime implementations now consistently support git_provider_tokens

This fixes the issue where git_provider_tokens were not available at runtime
initialization for repo microagents, eliminating the need for the antipattern
assignment in clone_or_init_repo.
@neubig neubig force-pushed the fix/bash-timeout-interactive-git-clone branch from a465dd0 to 9fb63ec Compare June 16, 2025 01:01
@openhands-ai
Copy link

openhands-ai bot commented Jun 16, 2025

Summary

I successfully identified and fixed the antipattern in the clone_or_init_repo function. Here's what was accomplished:

Root Cause Analysis

The antipattern self.git_provider_tokens = git_provider_tokens existed because:

  • AgentSession._create_runtime() only passed git_provider_tokens to RemoteRuntime instances
  • Non-RemoteRuntime implementations (DockerRuntime, LocalRuntime, E2BRuntime, etc.) didn't accept git_provider_tokens in their constructors
  • This meant git provider tokens were unavailable during runtime initialization for repo microagents, requiring the workaround

Solution Implemented

Removed the antipattern from clone_or_init_repo function in base.py

Updated all runtime constructors to accept git_provider_tokens:

  • DockerRuntime: Added git_provider_tokens, removed user_id (Docker doesn't need it)
  • LocalRuntime: Added both user_id and git_provider_tokens
  • E2BRuntime: Upgraded to inherit from ActionExecutionClient for consistency
  • ModalRuntime: Added user_id and git_provider_tokens
  • DaytonaRuntime: Added user_id and git_provider_tokens
  • RunloopRuntime: Added user_id and git_provider_tokens

Updated AgentSession._create_runtime() to pass git_provider_tokens to ALL runtime types

Added comprehensive test coverage in test_runtime_git_tokens.py

Benefits

  • Eliminated unexpected side effects: No more antipattern in clone_or_init_repo
  • Consistent architecture: All runtime implementations now properly support git_provider_tokens
  • Proper initialization: Git provider tokens are available from the start for repo microagents
  • Better maintainability: Code follows proper initialization patterns

Verification

  • All runtime constructors accept the new parameters correctly
  • Git provider tokens are properly passed through to the base Runtime class
  • Pre-commit hooks pass successfully
  • Changes have been pushed to the PR branch

The fix addresses the core issue: git_provider_tokens are now properly available at runtime initialization time for all runtime types, eliminating the need for the antipattern workaround.

openhands-agent and others added 2 commits June 16, 2025 01:03
All other runtime implementations accept user_id parameter, so DockerRuntime
should also accept it for consistency, even though Docker doesn't use it.
…ll-Hands-AI/OpenHands into fix/bash-timeout-interactive-git-clone
@neubig neubig marked this pull request as ready for review June 16, 2025 01:20
@neubig neubig requested a review from malhotra5 June 16, 2025 01:20
@ryanhoangt
Copy link
Collaborator

ryanhoangt commented Jun 16, 2025

I think the root cause is indeed the git clone waiting for credentials, below is the log of the last command (before agent's commands) I see inside the runtime:

12:01:07 - openhands:DEBUG: bash.py:602 - END OF PANE CONTENT: ['  "exit_code": "0",', '  "username": "openhands",', '  
"hostname": "hoang-dev",', '  "working_dir": "/workspace/starter-repo",', '  "py_interpreter_path": 
"/openhands/poetry/openhands-ai-5O4_aCHf-py3.12/bin/python"', '}', '###PS1END###', 'git clone --depth 1 
https://github.com/ryanhoangt/.openhands.git /workspace/org_openhands_ryanhoangt', "Cloning into 
'/workspace/org_openhands_ryanhoangt'...", "Username for 'https://github.com':"]
12:01:07 - openhands:DEBUG: bash.py:632 - CHECKING NO CHANGE TIMEOUT (10s): elapsed 10.100644588470459. 
Action blocking: False

One thing I don't quite understand yet is that it only happens for the forked starter-repo repo (as described in #9147), I tested a few of my other (non-forked) repos and the issue doesn't occur there.

@neubig neubig merged commit cbe32a1 into main Jun 16, 2025
19 checks passed
@neubig neubig deleted the fix/bash-timeout-interactive-git-clone branch June 16, 2025 12:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: First bash commands timing out immediately

5 participants