Replies: 10 comments 7 replies
|
thx for reporting. this is likely not a ralphex issue - ralphex uses the token from your host's claude session (mapped via a couple of things to check:
the token ralphex uses comes from the host claude session, so if it expires mid-run there's nothing ralphex can do about it. claude code is supposed to refresh tokens automatically, but if that's broken on their end it would explain the intermittent failures. |
|
Yeah, I'm on the last version and yes it works outside of the container in such moment. It does not happen constantly, it's rather random. I also faced similar issue with codex reviewer: Claude says it's by design but I doubt it is correct assessment: |
|
|
two separate things here: claude 401 (original issue): the token comes from your host's claude session. if claude works fine on the host at that exact moment, then it might be a claude code bug - they had issues with oauth token refresh in recent releases. pls check codex |
|
Yeah, these are two unrelated issues and yes none of it is ralphex fault. Let's leave it here if someone faces similar issues. |
|
@umputun I just caught the same issue with CC: 
As you can see CC is 2.1.81 |
|
thx for the update. one question though, what OS are you running on? credential propagation to Docker works differently on macOS (keychain extraction) vs Linux (file-based), need to know which path to look at |
|
Its macos 15.7.4 (sequoia) |
|
Well, probably some details about your configuration are missing because I run on macOS too with Docker (most of the time) and have never run into this issue. Without reproduction of the issue, not much I can do to even diagnose it. It sounds like something in your setup prevents Claude code from updating the auth token. I have no idea what exactly, my first suspicion would be some customization you added to ralphex-dk or some parameters you passed, or something along those lines. |
|
Yeah, this is very strange because the only config parameters I use in ralphex are telegram notifications settings and claude code config is also rather close to default: |
|
I'll try to debug the situation as it is still happening. Looks like a correct mapping? Claude I see mapped files and folders: 
Is there anything I can test from within the container at the event of failure? Maybe some more explicit API error would tell us more about the underlying reason of a failure? |
|
to clarify how credentials work in the container - the analysis from Claude you shared earlier is not quite right about the "read-only" problem. here's the actual flow:
so the container has a fully writable credential file and Claude Code should be able to refresh the token normally. the read-only mount is just for the initial transfer from host, not for runtime usage. the real question is why the refresh fails. one likely scenario - if you run Claude Code on the host (or start another container) while ralphex is running, that session may consume the refresh token first. OAuth refresh tokens are single-use, so the running container's refresh token becomes invalid. to debug next time it happens: since you're running in Docker, you can exec into the running container. when you see the 401 error, before the container exits: # find container ID
docker ps | grep ralphex
# check the token state inside
docker exec -it <container_id> sh -c 'cat /home/app/.claude/.credentials.json | python3 -c "import sys,json,time; d=json.load(sys.stdin); exp=d[\"claudeAiOauth\"][\"expiresAt\"]/1000; now=time.time(); print(f\"expired: {exp < now}, expires_at: {time.ctime(exp)}, now: {time.ctime(now)}, remaining: {(exp-now)/60:.0f}m\")"'
# try running claude manually to see the actual error
docker exec -it <container_id> su -c 'claude -p "hello"' app |
|
Thanks for such a detailed analysis. Yes, I usually run ralphex and still use claude on host machine for other tasks. So it may happen that there is an idle session of claude on host machine (one or more) while ralphex is working.
|
|
it depends. without understanding the root cause I can't recommend any particual solution |
|
@umputun every time it happens I usually have an idle (one or more) Claude sessions running on host machine. I'm not 100% positive yet, I'll double check and get back to you here. At least when I specifically killed all the host level sessions - there were no issues with ralphex. |
|
@umputun Unfortunately there have to be some other reason for the issue. I'm using ralphex on daily basis and yet sometimes it fails with this auth issue. I've tried to leave 3-4 sessions active outside of ralphex session and it had no influence on the result. There were no erorrs. Then again, I've started the ralphex plan at Timings looks really off. Especially for a small plan (there is little code to review). Macbook was not sleeping during the session. Maybe it is worth noting that I see this failure only in |
|
@umputun it still happening, unfortunately. A moment ago I've had repeated failure like this (3 consecutive failures): then I started claude code in terminal and it worked just fine. Afterwards I run the ralphex once again and it started working without any issues. I don't use anything specific. Ralphex config only contains the telegram settings. I cannot think of a reason for this failure. Nothing obvious comes to mind. The custom docker container isn't special at all too: #!/bin/sh
set -e
# Run original ralphex init (Claude/Codex credentials setup)
. /srv/init-ralphex.sh
# Catch-up sync: deps are pre-installed at build time, so this is a fast
# no-op unless uv.lock has changed since the image was built.
if [ -f /workspace/pyproject.toml ]; then
cd /workspace
if [ "${MYPROJECT_INFERENCE:-}" = "1" ]; then
uv sync --group dev --group inference
else
uv sync --group dev
fi
chown -R app:app /home/app/.venv
fi |
Uh oh!
There was an error while loading. Please reload this page.
Hi! I'm running ralphex in Docker (haha since it's installed some databases on it's own to my host OS) and I am experiencing the following issue from time to time:
It's not a usage issue for sure. It's probably not even a ralphex issue either since you only map the host directory into container...
All reactions