#1281·starship

Periodic prompt refresh

Author: catleeballCreated May 31, 2020Updated Sep 14, 2026
Labels✨ enhancement

Feature Request

It would be very nice if Starship could refresh the current prompt on a timer. This would allow interesting additional features for modules, and provide avenues for new modules that would be infeasible without a periodic updating prompt.

See alternative 1 below regarding a live prompt using event-driven prompt updates.

This would enable things like:

  • extending the Time module to optionally update, so the user can have a live clock in their prompt
  • animations in prompt (cycling characters for fun effects)
  • The infamous marquee tag, now in your prompt

Describe the solution you'd like

Modules that use this feature could expose an update-interval = int seconds flag in the config, where users can specify how fast the prompt will update. Possibly, also a flag to disable updates, like periodic-update = bool

[time]
disabled = false
periodic-update = true
update-interval = 10  # sufficient for minute-granularity time
time-format = "[%R]"

For performance and low spec machines, it might be best to recommend developers default modules to having periodic updates toggled off, where applicable. Some use cases where this wouldn't be applicable are some possible fun1 new modules:

[animation]
disabled = false
frames = ["", ""]
interval = 1
[inline-marquee]
disabled = false
# Prefix and Suffix are not animated to be marquee borders
prefix = "["
suffix = "]"
marquee-text = "this feature is deprecated"
# Rate to refresh prompt also impacts marquee speed
interval = 1 
[preprompt-marquee]
# Requires [line-break] = true
# Pre-prompt line will be marquee-ified
disabled = true
interval = 1

Describe alternatives you've considered

  1. Instead, this could be a callback hook instead of a refresh interval, where an event triggers Starship to update the prompt. This might be more flexible and efficient; modules do not need to wait for the next update interval to update, and only update when needed. Cons include complexity; this feature would likely need a considerable amount of work to implement, and developers who use it need to understand event-driven programming to use this feature. Further, effort would be needed to abstract this complexity away from users who want a simple config flag to do what they want.
  2. This could be user-implemented, where the shell itself is configured to re-evaluate starship on an interval. Pros include no work needed for Starship. Cons are that it would be less accessible to users (they need to figure out how to do this with their shell), and likely a lot slower (re-running starship init every N seconds likely incurs a lot of operations we don't actually need to re-run when we just want to refresh the display and update relevant modules)

1: Fun is subjective. Your milage may vary.