Idle timeout change not updating on next launch

[louisaslett]

Select Topic Area

Bug

Body

The documentation about default idle timeout states (emphasis mine):

[...] you can specify a longer or shorter default timeout period in your personal settings on GitHub. The updated setting will apply to any new codespaces you create, or to existing codespaces the next time you start them.

I believe there is a bug because this is not working per the documentation and I cannot see any way to change the idle timeout after an instance has been created. My experience shows that whatever the default idle timeout is set to at creation time sticks to that Codespace for its lifetime: stopping it, changing the timeout, and restarting still results in timeout at the setting during creation, not launch.

I have created a short (silent) video demonstrating the issue (click here to view) and provide a step-by-step guide through the video to reproduce the bug, each step starting with video timestamps (minute/seconds) in brackets:

1. (0m 0s) Confirm the current timeout (30 minutes).
2. (0m 4s) Launch a new Codespace.
3. (0m 27s) Stop the Codespace (I continue on to name this to keep track that this was launched before updating the idle timeout).
4. (0m 53s) Change the default idle timeout (here, to 70 minutes).
5. (1m 0s) Launch a new Codespace.
6. (1m 47s) Stop the Codespace (I continue on to name this to keep track that this was launched after updating the idle timeout).
7. (2m 10s) By this point both of the Codespaces are stopped and the default idle timeout setting is still 70 minutes. I proceed now to start both Codespaces up again.
8. (3m 8s) Both Codespaces are running in browser windows side-by-side and I interact with them a little, then start a stopwatch. After about 10 seconds I speed up the video 20x and you can see the stopwatch building up towards 30 minutes.
9. (5m 4s) The speeded up video has reached 28 minutes and 46 seconds idle according to the stopwatch. At this point, the Codespace which was created first shows a warning that it will soon terminate due to the idle timer, the other Codespace does not. However, both were launch while the default idle timer was set to 70 minutes.
10. (6m 8s) The first Codespace stops due to idle timeout at 30 minutes and 54 seconds on the stopwatch. The video then speeds up 20x shortly after to monitor when the second one stops.
11. (8m 11s) The Codespace which was created second shows a warning that it will soon terminate due to the idle timer.
12. (9m 14s) The second Codespace stops due to idle timeout at 69 minutes and 50 seconds on the stopwatch.
13. (9m 25s) We show that the default timer is indeed 70 minutes, meaning that both Codespaces should have timed out at about the same time, which is not what happened.

Conclusion: There is a bug which means that a Codespace is 'stuck' with whatever the default idle timeout was when it was created, which does not update upon launch, contradicting the documentation.

Many thanks for this amazing service ... this bug fix would be wonderful as I often want to mix up how interactive I'll be during a session if eg accessing a networked dev environment within the Codespace (the demo I showed is one where I have access to RStudio, but working interactively in RStudio does not count, understandably, to interrupt the idle timeout).

[louisaslett]

Do we know if folk from Github see bug reports here, or should I be making bug reports elsewhere? This is affecting a large University class I teach (220 students) and they are currently working in Codespaces which will need a longer timeout for an exam in January ... I do not relish the prospect of having to guide 200+ students through deleting and recreating their Codespace just because the timeout won't update to be long enough for the exam without creating a new Codespace after the idle time is changed!

I appreciate the fix might need time to implement, but just getting some acknowledgement it is on a Github engineer's radar would be something 😊

[JJ-Author]

I have the same issue.

But it seems even worse that idle activity is not determined correctly:
"Terminal activity, either input or output, also resets the idle timeout period." does not seem to work
I tried the following script in second terminal to make sure that my other process is not interrupted (which also produces output but I wanted to make sure)
while true; do date ; sleep 10; done
to let my codespace not becoming idle
but coming back an hour it is just stopped (idle timeout 30 minuts)

[codingmall]

I have the same issue.

But it seems even worse that idle activity is not determined correctly: "Terminal activity, either input or output, also resets the idle timeout period." does not seem to work I tried the following script in second terminal to make sure that my other process is not interrupted (which also produces output but I wanted to make sure) while true; do date ; sleep 10; done to let my codespace not becoming idle but coming back an hour it is just stopped (idle timeout 30 minuts)

I am facing the same problem. Do you find a solution?

[JJ-Author]

my workarounds were

• using "vscode tunnel" instead of codespaces on my own server and connecting via vscode.dev. you have very similar features compared to codespace but need your own server
• then opening in the shell pane tmux first and make sure to execute every command in there. this at least does not terminate my program after the timeout is triggered and after reconnect my session is gone but i can reconnect with tmux to the bash terminal that is still running my program