[burtenshaw]

This PR rolls the current open Dependabot environment dependency queue into a single reviewed update branch.

It refreshes the affected env manifests and lockfiles, adds PR-time validation for changed env lockfiles, and replaces the individual per-package env bumps with one branch that can be validated and merged coherently.

Validation:

• uv sync --frozen --all-groups --all-extras --dry-run --no-install-project passed for every affected env.
• Manual smoke checks passed for envs/websearch_env and envs/dipg_safety_env.
• Repo tests passed with PYTHONPATH=src:envs uv run pytest tests/ --ignore=tests/envs/test_browsergym_environment.py --ignore=tests/envs/test_dipg_environment.py --ignore=tests/envs/test_websearch_environment.py --ignore=tests/envs/test_python_codeact_reset.py --ignore=tests/envs/test_python_codeact_rewards.py --ignore=tests/envs/test_textarena_environment.py -m "not integration and not network and not docker" -v --tb=short.
• uv run ruff check src/ tests/ passed.

Supersedes the currently open Dependabot env PRs in this queue.

[greptile-apps]

Greptile Summary

This PR consolidates pending Dependabot env bumps — primarily requests>=2.33.0 and authlib patch releases — across 12 environment directories, refreshes the corresponding uv.lock files, and adds a new validate-env-locks CI job that runs uv sync --frozen --dry-run against every env whose lockfile or pyproject.toml changed in a PR.

The dependency changes themselves are routine and low-risk. The new CI job is a useful addition, but it installs only Python 3.11 while grid_world_env declares requires-python = \">=3.12\", which will cause the validation step to fail for that environment.

Confidence Score: 4/5

Safe to merge once the Python 3.11-vs-3.12 mismatch in the new CI job is fixed; all env dependency bumps are routine.

One P1 finding: the validate-env-locks job installs only Python 3.11 but grid_world_env requires >=3.12, so the job will fail for that environment on every PR that touches it. The fix is a one-line change. All other findings are P2 or lower and do not block merge.

.github/workflows/test.yml — the new validate-env-locks job needs Python 3.12 installed alongside 3.11.

Important Files Changed

Filename	Overview
.github/workflows/test.yml	Adds new validate-env-locks CI job; installs only Python 3.11, but grid_world_env requires >=3.12 — likely causes job failure for that env; also uses rg without installing it.
envs/grid_world_env/pyproject.toml	Bumps requests floor to >=2.33.0; retains requires-python = '>=3.12' which clashes with the new CI validation job's Python 3.11 install.
envs/finrl_env/pyproject.toml	Bumps requests to >=2.33.0; keeps websockets override for alpaca-trade-api conflict; lockfile refreshed.
envs/websearch_env/pyproject.toml	Bumps requests minimum from 2.31 to 2.33; no breaking changes introduced.
envs/dipg_safety_env/pyproject.toml	Lock refresh only; no pyproject.toml constraint changes detected beyond routine version alignment.
envs/reasoning_gym_env/pyproject.toml	Bumps reasoning-gym floor to >=0.1.24; no concerns.
envs/textarena_env/pyproject.toml	Lock refresh; textarena and nltk version floors unchanged; no concerns.
envs/echo_env/pyproject.toml	Lock refresh only; authlib bump is the trigger per git history; constraints unchanged.
envs/chat_env/pyproject.toml	Lock refresh for bundled authlib/requests bumps; no changes to declared constraints.
envs/snake_env/pyproject.toml	Bumps requests floor to >=2.33.0; all other pins unchanged.
envs/git_env/pyproject.toml	Bumps requests floor to >=2.33.0; no other changes.
envs/connect4_env/pyproject.toml	Lock refresh; no constraint changes.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    PR[Pull Request opened] --> CE[Checkout with full history]
    CE --> IU[Install uv 0.9.3]
    IU --> IP[Install Python 3.11 only]
    IP --> GD[git diff base..head filtered for env lockfiles]
    GD -->|no matches| SKIP[Exit 0 - nothing to validate]
    GD -->|env dirs found| LOOP[For each env directory]
    LOOP --> UV[uv sync --frozen --all-extras --dry-run]
    UV -->|requires-python 3.10+| OK[Validation passes]
    UV -->|requires-python 3.12+ but only 3.11 available| ERR[Python version mismatch - grid_world_env fails]
    OK --> NEXT[Next env dir]
    NEXT --> LOOP
    NEXT --> DONE[All envs validated]

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: .github/workflows/test.yml
Line: 33

Comment:
**Python 3.11 cannot validate `grid_world_env` (requires >=3.12)**

The job installs only Python 3.11, but `envs/grid_world_env/pyproject.toml` declares `requires-python = ">=3.12"` and its lockfile header also encodes `requires-python = ">=3.12"`. When `uv sync --frozen` runs inside that directory, uv will reject the active interpreter as incompatible and fail unless it can silently download Python 3.12 from its managed-Python store — which is not guaranteed in CI and was not explicitly enabled here. The validation will either crash on `grid_world_env` or silently skip the version check, both of which undermine the job's purpose.

Fix: install both Python versions and let uv pick the right one per environment:

```suggestion
      - name: Set up Python
        run: uv python install 3.11 3.12
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: .github/workflows/test.yml
Line: 41-45

Comment:
**`rg` assumed pre-installed without verification**

`ripgrep` is used here as if it's a guaranteed tool, but the step never installs it and the job has no explicit dependency on a runner image that ships with it. While `ubuntu-latest` GitHub-hosted runners do currently include `rg`, this is an undocumented soft guarantee that can break on image refreshes. Using `grep -E` (POSIX, always present) is safer and equally readable for this pattern.

```suggestion
          mapfile -t env_dirs < <(
            git diff --name-only "$base_sha" "$head_sha" \
              | grep -E '^envs/[^/]+/(pyproject\.toml|uv\.lock)$' \
              | xargs -r -n1 dirname \
              | sort -u
          )
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "chore: roll up dependabot env bumps" | Re-trigger Greptile}

[greptile-apps]

Python 3.11 cannot validate grid_world_env (requires >=3.12)

The job installs only Python 3.11, but envs/grid_world_env/pyproject.toml declares requires-python = ">=3.12" and its lockfile header also encodes requires-python = ">=3.12". When uv sync --frozen runs inside that directory, uv will reject the active interpreter as incompatible and fail unless it can silently download Python 3.12 from its managed-Python store — which is not guaranteed in CI and was not explicitly enabled here. The validation will either crash on grid_world_env or silently skip the version check, both of which undermine the job's purpose.

Fix: install both Python versions and let uv pick the right one per environment:

Suggested change

	run: uv python install 3.11
	- name: Set up Python
	run: uv python install 3.11 3.12

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/test.yml
Line: 33

Comment:
**Python 3.11 cannot validate `grid_world_env` (requires >=3.12)**

The job installs only Python 3.11, but `envs/grid_world_env/pyproject.toml` declares `requires-python = ">=3.12"` and its lockfile header also encodes `requires-python = ">=3.12"`. When `uv sync --frozen` runs inside that directory, uv will reject the active interpreter as incompatible and fail unless it can silently download Python 3.12 from its managed-Python store — which is not guaranteed in CI and was not explicitly enabled here. The validation will either crash on `grid_world_env` or silently skip the version check, both of which undermine the job's purpose.

Fix: install both Python versions and let uv pick the right one per environment:

```suggestion
      - name: Set up Python
        run: uv python install 3.11 3.12
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

rg assumed pre-installed without verification

ripgrep is used here as if it's a guaranteed tool, but the step never installs it and the job has no explicit dependency on a runner image that ships with it. While ubuntu-latest GitHub-hosted runners do currently include rg, this is an undocumented soft guarantee that can break on image refreshes. Using grep -E (POSIX, always present) is safer and equally readable for this pattern.

Suggested change

	git diff --name-only "$base_sha" "$head_sha" \
	| rg '^envs/[^/]+/(pyproject\.toml|uv\.lock)$' \
	| xargs -r -n1 dirname \
	| sort -u
	)
	mapfile -t env_dirs < <(
	git diff --name-only "$base_sha" "$head_sha" \
	| grep -E '^envs/[^/]+/(pyproject\.toml|uv\.lock)$' \
	| xargs -r -n1 dirname \
	| sort -u
	)

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/test.yml
Line: 41-45

Comment:
**`rg` assumed pre-installed without verification**

`ripgrep` is used here as if it's a guaranteed tool, but the step never installs it and the job has no explicit dependency on a runner image that ships with it. While `ubuntu-latest` GitHub-hosted runners do currently include `rg`, this is an undocumented soft guarantee that can break on image refreshes. Using `grep -E` (POSIX, always present) is safer and equally readable for this pattern.

```suggestion
          mapfile -t env_dirs < <(
            git diff --name-only "$base_sha" "$head_sha" \
              | grep -E '^envs/[^/]+/(pyproject\.toml|uv\.lock)$' \
              | xargs -r -n1 dirname \
              | sort -u
          )
```

How can I resolve this? If you propose a fix, please make it concise.